From gih@apnic.net Sun Dec 1 17:47:12 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC131AE170 for ; Sun, 1 Dec 2013 17:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.398 X-Spam-Level: X-Spam-Status: No, score=-99.398 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub3yc3hMqdxo for ; Sun, 1 Dec 2013 17:47:10 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [203.119.98.120]) by ietfa.amsl.com (Postfix) with SMTP id 65A061ADFF5 for ; Sun, 1 Dec 2013 17:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=cMn1xlzlYOzi3E8UnrGZH6k7MWnC2FkFFtiXTQDUbVQ=; b=1qAjN103Fx0B2RFRoQO7S9fh4QISEA2lzbUV88qO+43bQ/MriE0KFY0Hlldy8E68bvsrjCp+LmEOI OthreDcSQ1I8YNSZ1NJ9TPGKYlwyFz/ddifKHTEZEVI3FhxBSwT3L/jrRKAMeeT5b1nUWVDb9fTaRU 1nwdVv0PJcBzWWuM= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Mon, 2 Dec 2013 11:40:39 +1000 (EST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 2 Dec 2013 11:40:49 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Geoff Huston In-Reply-To: Date: Mon, 2 Dec 2013 12:40:47 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: LISP mailing list list X-Mailer: Apple Mail (2.1822) Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 02 Dec 2013 01:47:12 -0000 It may be minor, but the last sentence in section 4 is unclear. The txt = I see is: ---------------- The prefix must not be used as normal prefix and announced in the BGP routing infrastructure. in the BGP routing infrastructure. --------------- There is some error in the markup processing used to generate this = draft, but the more substantive comment is that I can't clearly parse the sentence. Did the authors mean: a) The prefix must not be used as normal prefix and must not be = announced in the BGP routing infrastructure. or b) The prefix must not be used as normal prefix but will (must?) be = announced in the BGP routing infrastructure. or c) something else I would prefer to see this resolved before saying "we're done!" which I = suppose is a "NO" response to the WGLC at this stage. regards, Geoff On 29 Nov 2013, at 12:39 pm, Terry Manderson = wrote: > All, >=20 > As requested in Vancouver, and after the authors updated the draft (to > -07) based on the Vancouver in-room discussion. >=20 > This starts a 14 day last call for this document, the last call will = end > on Friday the 13th December 2013. >=20 > You will find its text here: > http://www.ietf.org/id/draft-ietf-lisp-eid-block-07.txt >=20 > Please review this WG item and provide any last comments. >=20 > Cheers > Terry > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Sun Dec 1 18:02:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F171AE1DF for ; Sun, 1 Dec 2013 18:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjQcPL4gLb6G for ; Sun, 1 Dec 2013 18:02:19 -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 AE3E21AE1BD for ; Sun, 1 Dec 2013 18:02:19 -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; Sun, 1 Dec 2013 18:02:17 -0800 From: Terry Manderson To: LISP mailing list list Date: Sun, 1 Dec 2013 18:02:11 -0800 Thread-Topic: [lisp] WGLC draft-ietf-lisp-threats-08 Thread-Index: Ac7vAobg4+oTtAk3RCCRP7AdqJ81fw== 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.9.131030 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3468830531_41394082" MIME-Version: 1.0 Subject: Re: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 02 Dec 2013 02:02:20 -0000 --B_3468830531_41394082 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I would just like to highlight that the end of this LC draws near. Without review, this document cannot move forward. Cheers Terry On 20/11/13 9:23 AM, "Terry Manderson" wrote: >All, > >As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have >requested a work group last call. > >Here starts a 14 day last call for this document, the last call will end >on >Wednesday 4th December 2013. > >You will find its text here: >http://tools.ietf.org/html/draft-ietf-lisp-threats-08 > >Please review this WG item and provide any last comments. > >Cheers >Terry --B_3468830531_41394082 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 AQkEMRYEFMNVGH/7MyNuIIvT7n+o/L3zofjGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTIwMjAyMDIxMVowDQYJKoZIhvcNAQEBBQAEggEAfdCJKe+f l13NWZGCIdQRiGgZAkydWVZBoA9jIiK5CPQ8ATJu1zbWrceMXdv5LotXawMP4yaRZB1yYOuh FefSFl7JZunYcdqHCehATOJFT3z1StHJmZ+Q7azMW4rx2ti5LZeWd7wjBMeOnpPI9h4u12mm KQ6RmMDzbInGJ+eUt+CjdbJSp4S7WQZsVZQgQ1j/qNiD0eqoEVumnRuHp/GfcCjQK3nc86LU /q1V5d+Dd8Io71pa+ljV006K/fV5qfXT6k1J3WCT7h5+sp1fYgBTX86EwDljZhAGefcmRYpv 3pQDuXkBZQDpV2Yr2kr2HSTt38gnaTh4VQNvlPXe7CncEg== --B_3468830531_41394082-- From ggx@gigix.net Mon Dec 2 06:37:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DA11AE484 for ; Mon, 2 Dec 2013 06:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn2A38xODb4t for ; Mon, 2 Dec 2013 06:37:07 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6786E1AE483 for ; Mon, 2 Dec 2013 06:37:07 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id b13so8962466wgh.18 for ; Mon, 02 Dec 2013 06:37:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LtMW7xYaTOnFOIJhVuuw7oIkkgtegQ3nKR+gi6C83Tc=; b=kQI7It8b4VtXdpvh6u+kHWQKpq6KaAMaUieWTEMak527xOiGFgJnF1xJFM4PoXn3Yu d8U919rygFQcz7Gy+4XlJtf7yDfpqWFWAcNOitDxu4+TdiDSo+uXUCEFdf3zpxAIKdCS GhHVqbDLg1ID2NE9FgeGcyvQ6LKq6SHwHQZgza/cIV8UmPIQs7zdPIO7ZyPEL/Utr7o3 /t5kFsFi//2DcDiIPQ9xfX8hhXWMzs56BIAQL8SyJmO1UikkWQ/Qh/449vyfS+HXRXgF VU2dRKbfE6KBnkcqHR+4F7ReKsn5rN2rW0k7E6+do1cjKJTphObOkyyByHBYuFIVlyjm xaSA== X-Gm-Message-State: ALoCoQn5fbmv9gzug8Y0MHS653QKf73qFNyD91p+N+GL8CsmrwRU7CTOmR7lVwBj39IKhuaEDzFB X-Received: by 10.180.108.132 with SMTP id hk4mr18436870wib.12.1385995024450; Mon, 02 Dec 2013 06:37:04 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:38b2:56f:32c7:f711? ([2001:660:330f:a4:38b2:56f:32c7:f711]) by mx.google.com with ESMTPSA id n6sm103100344wix.3.2013.12.02.06.37.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 06:37:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luigi Iannone In-Reply-To: Date: Mon, 2 Dec 2013 15:37:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Geoff Huston X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 02 Dec 2013 14:37:10 -0000 Hi Geoff, I agree that the sentence is unclear. The purpose was to make sure that people do not get an IP prefix for = free and inject it in BGP, so it is close your interpretation a). What about the following text: The prefix must be used for LISP experimentation and must not be=20 used as normal prefix, hence, it must be used according to [RFC6832]=20 and [I-D.ietf-lisp-deployment] and must not be natively announced in the=20= BGP routing infrastructure.=20 Would this solve the issue? Luigi =20 > The prefix must not be used as normal prefix and must not be announced = in the BGP > routing infrastructure. On 2 Dec. 2013, at 02:40 , Geoff Huston wrote: > It may be minor, but the last sentence in section 4 is unclear. The = txt I see is: >=20 >=20 > ---------------- >=20 > The prefix must not be used as normal prefix and announced in the BGP > routing infrastructure. >=20 >=20 >=20 >=20 >=20 >=20 > in the BGP > routing infrastructure. >=20 > --------------- >=20 > There is some error in the markup processing used to generate this = draft, but the more > substantive comment is that I can't clearly parse the sentence. >=20 > Did the authors mean: >=20 >=20 > a) The prefix must not be used as normal prefix and must not be = announced in the BGP > routing infrastructure. >=20 > or >=20 > b) The prefix must not be used as normal prefix but will (must?) be = announced in the BGP > routing infrastructure. >=20 > or >=20 > c) something else >=20 >=20 > I would prefer to see this resolved before saying "we're done!" which = I suppose is a > "NO" response to the WGLC at this stage. >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >=20 > On 29 Nov 2013, at 12:39 pm, Terry Manderson = wrote: >=20 >> All, >>=20 >> As requested in Vancouver, and after the authors updated the draft = (to >> -07) based on the Vancouver in-room discussion. >>=20 >> This starts a 14 day last call for this document, the last call will = end >> on Friday the 13th December 2013. >>=20 >> You will find its text here: >> http://www.ietf.org/id/draft-ietf-lisp-eid-block-07.txt >>=20 >> Please review this WG item and provide any last comments. >>=20 >> Cheers >> Terry >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From sander@steffann.nl Mon Dec 2 11:48:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1EC1AC4A7 for ; Mon, 2 Dec 2013 11:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH9K1H_wM0X5 for ; Mon, 2 Dec 2013 11:48:26 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1E1A1F5F for ; Mon, 2 Dec 2013 11:48:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 86CC845; Mon, 2 Dec 2013 20:48:22 +0100 (CET) X-Virus-Scanned: Debian 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 b8wOfEuBuI2W; Mon, 2 Dec 2013 20:48:20 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 5420137; Mon, 2 Dec 2013 20:48:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Sander Steffann In-Reply-To: Date: Mon, 2 Dec 2013 20:48:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C2DB611-D0D1-4784-AF00-BFEE58872801@steffann.nl> References: To: Luigi Iannone X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 02 Dec 2013 19:48:27 -0000 Hi, > What about the following text: >=20 > The prefix must be used for LISP experimentation and must not be=20 > used as normal prefix, hence, it must be used according to [RFC6832]=20= > and [I-D.ietf-lisp-deployment] and must not be natively announced in = the=20 > BGP routing infrastructure.=20 >=20 > Would this solve the issue? That would mean that it is not allowed to be announced in BGP at all, = which would mean that it is not possible to run PITRs for it. Is that = really the intention? Cheers, Sander From gih@apnic.net Mon Dec 2 11:56:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D605E1ADBFF for ; Mon, 2 Dec 2013 11:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emDluGjObNhS for ; Mon, 2 Dec 2013 11:56:50 -0800 (PST) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 0A67B1AD845 for ; Mon, 2 Dec 2013 11:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:content-type:mime-version:subject:from:in-reply-to: date:cc:content-transfer-encoding:message-id:references:to:x-mailer: return-path; bh=5Z/QV3y0WxQ+Asr4vs1iLcxVtLTxDimYECWyY4F5t6c=; b=FVB6FvO3w7RTNEXxOkgG5p1nJSwiRM0VJVovFJweGGTUZoBHNyL/K4GdypTScRLmJLwoDDMhqTsO+ BmTxgH25GP+LiZlpZlmh2TU7TS1aq2C99thdOLGQsXVEgkthDu7BDNxL7nLUKGOwLOFuXlApEtibNt U2fWIbMw5uTSGeTQ= Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 3 Dec 2013 05:56:44 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by IAMDA1.org.apnic.net (2001:dd8:a:852::11) with Microsoft SMTP Server (TLS) id 14.1.421.2; Tue, 3 Dec 2013 05:56:44 +1000 Received: from dhcp150.potaroo.net (203.119.101.249) by IAMDA2.org.apnic.net (203.119.111.21) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 3 Dec 2013 05:56:44 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Geoff Huston In-Reply-To: Date: Tue, 3 Dec 2013 06:56:42 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> References: To: Luigi Iannone X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 02 Dec 2013 19:56:53 -0000 I'm afraid thats its still unclear to me - "natively announced" is a = term I do not understand. Are you saying that all more specifics _and_ the aggregate /32 itself = must not be advertised into the IPv6 global unicast network? Or are you saying that all more specifics of this /32 must not be = advertised into IPv6 global unicast network, but the aggregate /32 = should (must?) be advertised? i.e. is this /32 unreachable from the rest of the IPv6 net in its = entirety, ore are you saying that any LISP gateways into this /32 must = advertise the entire /32 and not just advertise more specifics? regards, Geoff On 3 Dec 2013, at 1:37 am, Luigi Iannone wrote: > Hi Geoff, >=20 > I agree that the sentence is unclear. >=20 > The purpose was to make sure that people do not get an IP prefix for = free and inject it in BGP, so it is close your interpretation a). >=20 > What about the following text: >=20 > The prefix must be used for LISP experimentation and must not be=20 > used as normal prefix, hence, it must be used according to [RFC6832]=20= > and [I-D.ietf-lisp-deployment] and must not be natively announced in = the=20 > BGP routing infrastructure.=20 >=20 > Would this solve the issue? >=20 > Luigi >=20 >=20 >=20 >> The prefix must not be used as normal prefix and must not be = announced in the BGP >> routing infrastructure. >=20 >=20 >=20 >=20 > On 2 Dec. 2013, at 02:40 , Geoff Huston wrote: >=20 >> It may be minor, but the last sentence in section 4 is unclear. The = txt I see is: >>=20 >>=20 >> ---------------- >>=20 >> The prefix must not be used as normal prefix and announced in the BGP >> routing infrastructure. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> in the BGP >> routing infrastructure. >>=20 >> --------------- >>=20 >> There is some error in the markup processing used to generate this = draft, but the more >> substantive comment is that I can't clearly parse the sentence. >>=20 >> Did the authors mean: >>=20 >>=20 >> a) The prefix must not be used as normal prefix and must not be = announced in the BGP >> routing infrastructure. >>=20 >> or >>=20 >> b) The prefix must not be used as normal prefix but will (must?) be = announced in the BGP >> routing infrastructure. >>=20 >> or >>=20 >> c) something else >>=20 >>=20 >> I would prefer to see this resolved before saying "we're done!" = which I suppose is a >> "NO" response to the WGLC at this stage. >>=20 >> regards, >>=20 >> Geoff >>=20 >>=20 >>=20 >>=20 >> On 29 Nov 2013, at 12:39 pm, Terry Manderson = wrote: >>=20 >>> All, >>>=20 >>> As requested in Vancouver, and after the authors updated the draft = (to >>> -07) based on the Vancouver in-room discussion. >>>=20 >>> This starts a 14 day last call for this document, the last call will = end >>> on Friday the 13th December 2013. >>>=20 >>> You will find its text here: >>> http://www.ietf.org/id/draft-ietf-lisp-eid-block-07.txt >>>=20 >>> Please review this WG item and provide any last comments. >>>=20 >>> Cheers >>> Terry >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From ggx@gigix.net Tue Dec 3 13:29:49 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFFA1ADED6 for ; Tue, 3 Dec 2013 13:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QipVHrSI9X8q for ; Tue, 3 Dec 2013 13:29:47 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4C751A8032 for ; Tue, 3 Dec 2013 13:29:46 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so8529428wes.17 for ; Tue, 03 Dec 2013 13:29:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=kwxhCsBJDjQtXtEECtCHu6S0Sz+KW7CC8YgWoQHpG8c=; b=jmemD1SbK+A+9K14sHfmCOMzjFjH5IXp4qvPlVhi6CTBo0QbHUiBAI0pb+Ru6u8sOQ XFBlGYKpQ8jYEjMzc2GwxhYJ0h7Y21P9NTAok/l8zymDRqYV9L7i1dhB7ZT/8G3R0cxg oKe93NFsqm/YBLSYR15MDF+x1KaYHFAYxUULxV9V0RgoDFxI+aNfAgm9ZwRAqSfDywn8 8hDMiCNsWKKQuXcV3NXOaYIaSsd9AsZ6nwW05Kf3y3JTEqzs2hFNTKM2FerYLZDWoC2t VsGCQGi4vO4Yva/bFThLzfJD59+uXulIij/fvijqRo/IygB3ORGP2Cn4ECT47F9BuImx nycg== X-Gm-Message-State: ALoCoQlZhGlj9zzLacuBYqK96a4wDgzUGkiY30gzGUNnhjn4/rW32OcrpAVhMw5CsFFOG3yzDsBm X-Received: by 10.194.122.131 with SMTP id ls3mr36171626wjb.0.1386106183443; Tue, 03 Dec 2013 13:29:43 -0800 (PST) Received: from ?IPv6:2a01:e35:1381:3430:6559:5c85:573a:8e65? ([2a01:e35:1381:3430:6559:5c85:573a:8e65]) by mx.google.com with ESMTPSA id nb16sm668632wic.0.2013.12.03.13.29.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 13:29:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luigi Iannone In-Reply-To: <2C2DB611-D0D1-4784-AF00-BFEE58872801@steffann.nl> Date: Tue, 3 Dec 2013 22:29:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3285CBC9-9FA9-4ED4-B56B-7605F784FB23@gigix.net> References: <2C2DB611-D0D1-4784-AF00-BFEE58872801@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 03 Dec 2013 21:29:49 -0000 Hi Steffan, On 2 Dec. 2013, at 20:48 , Sander Steffann wrote: [snip] >>=20 >> Would this solve the issue? >=20 > That would mean that it is not allowed to be announced in BGP at all, = which would mean that it is not possible to run PITRs for it. Is that = really the intention? >=20 No, that is not the intention, that is why there is a reference to the = interworking RFC 6832. Luigi > Cheers, > Sander >=20 From ggx@gigix.net Tue Dec 3 13:44:51 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501B61ADF7F for ; Tue, 3 Dec 2013 13:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMEITeApTwIG for ; Tue, 3 Dec 2013 13:44:48 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id A0EAA1ADF48 for ; Tue, 3 Dec 2013 13:44:48 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x13so14276191wgg.19 for ; Tue, 03 Dec 2013 13:44:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QOP74In+QzwFAayXQC83xUw9qdATfpidwF6u18UKQvU=; b=Eb0rbc40AH9aaGrOyJVgIVSD89DsSkSgvzFql6Spl9vCKqSR6N7WpHvfWMMqR++M91 nd/Z3gdBkbtzm3bchyH59gUdoRgwqMpA/0xvIRrpckimJsihXkRr9YzwJSSZaKFJFuHC N9EGLyar4k9cuCyc4XUCccy7NN/V/LdbwUpWpw760U2zAkO/00gn9kGqIkTpFrrgnVyD n4AKOq6p0Dj9mYJBLP7skytZMA1MWguOWpnr/LYukKufF+W3OlTvuUR//9Ev5kNB3X0u IAXfgF7dNJsqtBE3CsHgr8GXp772h9sSCkJB1nMRP30Xo7bcMTOB3HGSgjw1aDCAkk3T tkrw== X-Gm-Message-State: ALoCoQnBy5LyS+SFVE/IwuXueMRmW+41JOZlEG+exX0X1r+O4DzEa0j/AbviYTZjILs4IAaxUW3y X-Received: by 10.181.11.197 with SMTP id ek5mr4343248wid.7.1386107085327; Tue, 03 Dec 2013 13:44:45 -0800 (PST) Received: from ?IPv6:2a01:e35:1381:3430:6559:5c85:573a:8e65? ([2a01:e35:1381:3430:6559:5c85:573a:8e65]) by mx.google.com with ESMTPSA id s20sm770165wib.1.2013.12.03.13.44.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 13:44:44 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luigi Iannone In-Reply-To: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> Date: Tue, 3 Dec 2013 22:44:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> To: Geoff Huston , Sander Steffann X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 03 Dec 2013 21:44:51 -0000 Hi Geoff, as I said to Steffan, there is a reference to rfc 6832 that covers = interworking, that should be used as reference. PITR should announce the largest aggregate possible, ideally the /32. Let=92s try again ;-) The prefix must be used for LISP experimentation and must not be=20 used as normal prefix. Interworking between the EID block prefix=20 and the non-LISP Internet is done according to [RFC6832]=20 and [I-D.ietf-lisp-deployment]. Better? Luigi On 2 Dec. 2013, at 20:56 , Geoff Huston wrote: > I'm afraid thats its still unclear to me - "natively announced" is a = term I do not understand. >=20 > Are you saying that all more specifics _and_ the aggregate /32 itself = must not be advertised into the IPv6 global unicast network? >=20 > Or are you saying that all more specifics of this /32 must not be = advertised into IPv6 global unicast network, but the aggregate /32 = should (must?) be advertised? >=20 > i.e. is this /32 unreachable from the rest of the IPv6 net in its = entirety, ore are you saying that any LISP gateways into this /32 must = advertise the entire /32 and not just advertise more specifics? >=20 >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >=20 >=20 >=20 > On 3 Dec 2013, at 1:37 am, Luigi Iannone wrote: >=20 >> Hi Geoff, >>=20 >> I agree that the sentence is unclear. >>=20 >> The purpose was to make sure that people do not get an IP prefix for = free and inject it in BGP, so it is close your interpretation a). >>=20 >> What about the following text: >>=20 >> The prefix must be used for LISP experimentation and must not be=20 >> used as normal prefix, hence, it must be used according to [RFC6832]=20= >> and [I-D.ietf-lisp-deployment] and must not be natively announced in = the=20 >> BGP routing infrastructure.=20 >>=20 >> Would this solve the issue? >>=20 >> Luigi >>=20 >>=20 >>=20 >>> The prefix must not be used as normal prefix and must not be = announced in the BGP >>> routing infrastructure. >>=20 >>=20 >>=20 >>=20 >> On 2 Dec. 2013, at 02:40 , Geoff Huston wrote: >>=20 >>> It may be minor, but the last sentence in section 4 is unclear. The = txt I see is: >>>=20 >>>=20 >>> ---------------- >>>=20 >>> The prefix must not be used as normal prefix and announced in the = BGP >>> routing infrastructure. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> in the BGP >>> routing infrastructure. >>>=20 >>> --------------- >>>=20 >>> There is some error in the markup processing used to generate this = draft, but the more >>> substantive comment is that I can't clearly parse the sentence. >>>=20 >>> Did the authors mean: >>>=20 >>>=20 >>> a) The prefix must not be used as normal prefix and must not be = announced in the BGP >>> routing infrastructure. >>>=20 >>> or >>>=20 >>> b) The prefix must not be used as normal prefix but will (must?) be = announced in the BGP >>> routing infrastructure. >>>=20 >>> or >>>=20 >>> c) something else >>>=20 >>>=20 >>> I would prefer to see this resolved before saying "we're done!" = which I suppose is a >>> "NO" response to the WGLC at this stage. >>>=20 >>> regards, >>>=20 >>> Geoff >>>=20 >>>=20 >>>=20 >>>=20 >>> On 29 Nov 2013, at 12:39 pm, Terry Manderson = wrote: >>>=20 >>>> All, >>>>=20 >>>> As requested in Vancouver, and after the authors updated the draft = (to >>>> -07) based on the Vancouver in-room discussion. >>>>=20 >>>> This starts a 14 day last call for this document, the last call = will end >>>> on Friday the 13th December 2013. >>>>=20 >>>> You will find its text here: >>>> http://www.ietf.org/id/draft-ietf-lisp-eid-block-07.txt >>>>=20 >>>> Please review this WG item and provide any last comments. >>>>=20 >>>> Cheers >>>> Terry >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 From rbonica@juniper.net Wed Dec 4 07:26:35 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E8F1ADF0F for ; Wed, 4 Dec 2013 07:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxhmMrIMdcZL for ; Wed, 4 Dec 2013 07:26:33 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF5E1ACB4E for ; Wed, 4 Dec 2013 07:26:33 -0800 (PST) Received: from mail69-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE021.bigfish.com (10.243.66.84) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 15:26:30 +0000 Received: from mail69-co1 (localhost [127.0.0.1]) by mail69-co1-R.bigfish.com (Postfix) with ESMTP id 100C8680CA4; Wed, 4 Dec 2013 15:26:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail69-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51704005)(54356001)(79102001)(74316001)(81342001)(63696002)(69226001)(83322001)(80976001)(76576001)(74706001)(56816005)(33646001)(90146001)(59766001)(83072001)(47446002)(77982001)(76482001)(85306002)(65816001)(51856001)(87266001)(81816001)(66066001)(80022001)(87936001)(77096001)(56776001)(54316002)(49866001)(50986001)(47976001)(4396001)(53806001)(31966008)(46102001)(74502001)(74876001)(74662001)(74366001)(76796001)(47736001)(81542001)(76786001)(81686001)(2656002)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail69-co1 (localhost.localdomain [127.0.0.1]) by mail69-co1 (MessageSwitch) id 1386170787535493_8903; Wed, 4 Dec 2013 15:26:27 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.250]) by mail69-co1.bigfish.com (Postfix) with ESMTP id 74268AC0074; Wed, 4 Dec 2013 15:26:27 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 15:26:27 +0000 Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 15:26:22 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.825.14; Wed, 4 Dec 2013 15:26:20 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Wed, 4 Dec 2013 15:26:20 +0000 From: Ronald Bonica To: Luigi Iannone , Geoff Huston , Sander Steffann Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TA= Date: Wed, 4 Dec 2013 15:26:19 +0000 Message-ID: <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 15:26:35 -0000 >=20 > PITR should announce the largest aggregate possible, ideally the /32. >=20 Luigi, Is this really what is going to happen?=20 If a PITR announces the entire /32 into the global Internet, it puts itself= on the forwarding path for the entire /32, and incurs the cost associated = with transporting traffic towards every site in that /32. This is supportab= le only if the PITR operator is somehow compensated for carrying all of tha= t traffic. Isn't it more likely that the PITR operator will advertise only slices of t= he /32, with each of those slices being assigned to either its customers (f= rom whom it collects revenue) or the customers of other operators with whom= it has made financial arrangements? Ron From brian@innovationslab.net Wed Dec 4 08:32:00 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00811AE2CC for ; Wed, 4 Dec 2013 08:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNpCsLQ-_PRy for ; Wed, 4 Dec 2013 08:31:59 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD691AE078 for ; Wed, 4 Dec 2013 08:31:59 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8E245880ED for ; Wed, 4 Dec 2013 08:31:56 -0800 (PST) Received: from 10252256.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 42B12130003 for ; Wed, 4 Dec 2013 08:31:56 -0800 (PST) Message-ID: <529F58F2.5020408@innovationslab.net> Date: Wed, 04 Dec 2013 11:31:46 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: lisp@ietf.org References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6DQwLxD4iflNTFACLdJOSP2HMJiEMQTor" Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 16:32:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6DQwLxD4iflNTFACLdJOSP2HMJiEMQTor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/4/13 10:26 AM, Ronald Bonica wrote: >>=20 >> PITR should announce the largest aggregate possible, ideally the >> /32. >>=20 >=20 > Luigi, >=20 > Is this really what is going to happen? >=20 The above is why I explicitly mentioned the pain felt by 6to4 relay routers during the Vancouver meeting. Advertising the entire range is not a good idea. > If a PITR announces the entire /32 into the global Internet, it puts > itself on the forwarding path for the entire /32, and incurs the cost > associated with transporting traffic towards every site in that /32. > This is supportable only if the PITR operator is somehow compensated > for carrying all of that traffic. >=20 > Isn't it more likely that the PITR operator will advertise only > slices of the /32, with each of those slices being assigned to either > its customers (from whom it collects revenue) or the customers of > other operators with whom it has made financial arrangements? I would hope this would be the case. Regards, Brian --6DQwLxD4iflNTFACLdJOSP2HMJiEMQTor Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSn1j4AAoJEBOZRqCi7goqLyAH/RoX6Up/Y0HmGvCKZySO1YhK C7fXD2rxSBdy0kMthWF1xJhQFwyLgocdya0qW2A10dLFqGbORwCJJHulrakP+d7l LN3d37SVReqOR132DJKpU31L1pldFtJGYNY+2Mnn0D1pPH1VSftctWaASs9q8UDs ErpYOQcO9+ZXbiYudS9jvw5EEmn6vTjZTAljzqVm09qU8/+6XWDDpgxRLcfkIr0K gk/o7dqJcRaN2nWNrQCI462PCZ6+J51wEqopoeGO9v1utOF15bwnzxuse7lNAGMa MPLZLnHTsVns+IbeKrsEjN5vVWsly74Mw6J4u1IsEegC3xZE9awyYM5LVvfvAmI= =XZ4C -----END PGP SIGNATURE----- --6DQwLxD4iflNTFACLdJOSP2HMJiEMQTor-- From farinacci@gmail.com Wed Dec 4 08:44:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D56D1AE2F3 for ; Wed, 4 Dec 2013 08:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJa6WQKjWGRn for ; Wed, 4 Dec 2013 08:44:39 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 766E41AE2EE for ; Wed, 4 Dec 2013 08:44:39 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so27374684ieb.32 for ; Wed, 04 Dec 2013 08:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u2E69hTmUEEBBAeQI9XtqN7XWCMxUroU8EmFFJOrjow=; b=xOwf8PKgbPOSpJbyUI5wh4V8Y4ZPE17lVR3CJOdzhMANCzgNd81E6Yym9CfQ5nVx3J KaTiQl5EyDDsqsrbHOi69mS7xNr5ErbKCl6bTHFAmdRIuChGtkR51KayqHAJl+GtWqG/ 1V4hA2wXFRiCTaJdlsK7cCB/rEpCicEKVaWuNR9l7PJ+0Munwgolf0eIOO1hxJ2SUSkx Rc39+9WNJb9sIzRlI/ajyR288h/mQgOOcRdP4pUYLsmXBDZiapS2CCMC2DXU8WOMatk9 9QHOQtN8D460lAOWECXOGCNPllL7p4wLSsi7ueBYCU8OzDxzdcgME1ocTbRIKlGblcpt 9Veg== X-Received: by 10.43.8.66 with SMTP id or2mr50250613icb.19.1386175476325; Wed, 04 Dec 2013 08:44:36 -0800 (PST) Received: from [172.19.131.154] ([12.130.127.16]) by mx.google.com with ESMTPSA id a17sm5061597ign.2.2013.12.04.08.44.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 08:44:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> Date: Wed, 4 Dec 2013 08:44:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 16:44:41 -0000 > Luigi, >=20 > Is this really what is going to happen?=20 >=20 > If a PITR announces the entire /32 into the global Internet, it puts = itself on the forwarding path for the entire /32, and incurs the cost = associated with transporting traffic towards every site in that /32. = This is supportable only if the PITR operator is somehow compensated for = carrying all of that traffic. But maybe only from a few sources. But if the /32 needs to be divided = based on region, then maybe /40s could be advertised. But to the point = about "few sources", the more PITRs there are, the better the load is = shared.=20 And I envision PITRs will be deployed on on-path boxes anyways. Those = boxes right now can route to the entire Internet, they are called PE = boxes, are they not Ron? > Isn't it more likely that the PITR operator will advertise only slices = of the /32, with each of those slices being assigned to either its = customers (from whom it collects revenue) or the customers of other = operators with whom it has made financial arrangements? No it won't be that way. EIDs are provider independent. If you do what = we suggest, we make no forward progress. Dino >=20 > Ron >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rbonica@juniper.net Wed Dec 4 08:51:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951DA1ABBB1 for ; Wed, 4 Dec 2013 08:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eteU7TJzq6rd for ; Wed, 4 Dec 2013 08:51:39 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 79A231A1F7C for ; Wed, 4 Dec 2013 08:51:39 -0800 (PST) Received: from mail86-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE028.bigfish.com (10.243.66.91) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 16:51:35 +0000 Received: from mail86-co1 (localhost [127.0.0.1]) by mail86-co1-R.bigfish.com (Postfix) with ESMTP id E6A8EC0097C; Wed, 4 Dec 2013 16:51:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hz8dhz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail86-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377454003)(51704005)(199002)(189002)(74316001)(74876001)(54356001)(80022001)(76482001)(87936001)(81816001)(66066001)(77096001)(33646001)(46102001)(79102001)(47446002)(76786001)(76576001)(51856001)(56816005)(90146001)(74706001)(65816001)(53806001)(1411001)(63696002)(19580405001)(81686001)(81542001)(83072001)(74502001)(83322001)(31966008)(80976001)(85306002)(74662001)(2656002)(4396001)(47736001)(87266001)(54316002)(19580395003)(50986001)(76796001)(47976001)(49866001)(74366001)(15975445006)(81342001)(56776001)(77982001)(69226001)(59766001)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail86-co1 (localhost.localdomain [127.0.0.1]) by mail86-co1 (MessageSwitch) id 1386175894445573_31963; Wed, 4 Dec 2013 16:51:34 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.240]) by mail86-co1.bigfish.com (Postfix) with ESMTP id 68AEC640055; Wed, 4 Dec 2013 16:51:34 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 16:51:32 +0000 Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 16:51:30 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.825.14; Wed, 4 Dec 2013 16:51:29 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Wed, 4 Dec 2013 16:51:28 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0w Date: Wed, 4 Dec 2013 16:51:27 +0000 Message-ID: <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> In-Reply-To: <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 16:51:41 -0000 Dino, I am not understanding your response. Let me ask the question another way. Assume that an operator deploys a PITR. What policy can that operator enfor= ce to ensure that it is compensated for all (or even most) of the traffic t= hat it carries across that PITR? Ron > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Wednesday, December 04, 2013 11:44 AM > To: Ronald Bonica > Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list > list > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >=20 > > Luigi, > > > > Is this really what is going to happen? > > > > If a PITR announces the entire /32 into the global Internet, it puts > itself on the forwarding path for the entire /32, and incurs the cost > associated with transporting traffic towards every site in that /32. > This is supportable only if the PITR operator is somehow compensated > for carrying all of that traffic. >=20 > But maybe only from a few sources. But if the /32 needs to be divided > based on region, then maybe /40s could be advertised. But to the point > about "few sources", the more PITRs there are, the better the load is > shared. >=20 > And I envision PITRs will be deployed on on-path boxes anyways. Those > boxes right now can route to the entire Internet, they are called PE > boxes, are they not Ron? >=20 > > Isn't it more likely that the PITR operator will advertise only > slices of the /32, with each of those slices being assigned to either > its customers (from whom it collects revenue) or the customers of other > operators with whom it has made financial arrangements? >=20 > No it won't be that way. EIDs are provider independent. If you do what > we suggest, we make no forward progress. >=20 > Dino >=20 > > > > Ron > > > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 From jmh@joelhalpern.com Wed Dec 4 09:01:56 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2491AE2D4 for ; Wed, 4 Dec 2013 09:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfTv1Fe-e_sa for ; Wed, 4 Dec 2013 09:01:55 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 54EA51AE157 for ; Wed, 4 Dec 2013 09:01:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9B6381C421DE; Wed, 4 Dec 2013 09:01:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [62.49.66.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8A8AF1C4220D; Wed, 4 Dec 2013 09:01:50 -0800 (PST) Message-ID: <529F5FFA.6000201@joelhalpern.com> Date: Wed, 04 Dec 2013 12:01:46 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ronald Bonica , Dino Farinacci References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 17:01:57 -0000 A partial answer that has been suggested is that the oeprator who deploys the PITR is an EID allocator rather than a conventional / existing ISP. Unfortunately, if LISp succeeds it is not clear that the compensation levels can match the increasing demand for traffic in the critical periods. Yours, Joel On 12/4/13 11:51 AM, Ronald Bonica wrote: > Dino, > > I am not understanding your response. Let me ask the question another way. > > Assume that an operator deploys a PITR. What policy can that operator enforce to ensure that it is compensated for all (or even most) of the traffic that it carries across that PITR? > > Ron > > >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, December 04, 2013 11:44 AM >> To: Ronald Bonica >> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list >> list >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >> >>> Luigi, >>> >>> Is this really what is going to happen? >>> >>> If a PITR announces the entire /32 into the global Internet, it puts >> itself on the forwarding path for the entire /32, and incurs the cost >> associated with transporting traffic towards every site in that /32. >> This is supportable only if the PITR operator is somehow compensated >> for carrying all of that traffic. >> >> But maybe only from a few sources. But if the /32 needs to be divided >> based on region, then maybe /40s could be advertised. But to the point >> about "few sources", the more PITRs there are, the better the load is >> shared. >> >> And I envision PITRs will be deployed on on-path boxes anyways. Those >> boxes right now can route to the entire Internet, they are called PE >> boxes, are they not Ron? >> >>> Isn't it more likely that the PITR operator will advertise only >> slices of the /32, with each of those slices being assigned to either >> its customers (from whom it collects revenue) or the customers of other >> operators with whom it has made financial arrangements? >> >> No it won't be that way. EIDs are provider independent. If you do what >> we suggest, we make no forward progress. >> >> Dino >> >>> >>> Ron >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From farinacci@gmail.com Wed Dec 4 09:18:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430D61AE30B for ; Wed, 4 Dec 2013 09:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf90ADFOwyEy for ; Wed, 4 Dec 2013 09:18:02 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 945871AE304 for ; Wed, 4 Dec 2013 09:18:02 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so26109835iej.26 for ; Wed, 04 Dec 2013 09:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=49eLP767Z3Mkwh3WUW1ol2T4jd+fxfXNC0JyFpmYh8Y=; b=bo2G/HplGc/NORxYiyYn/8k+ib3a7awroiZQ8aglUVCSrK1jzuOsrkqyua35w1WP12 ht/4mEQgxX0JzKUD2kzb1TJb0E4xCWKqPwZP87NkXvXNxhNmwPzSQV9Sij0clSyno5Dc fAy8W1h4JHvgqiGIB/qEXEJdI8O878jHNnV3hpsvdgL6F37ildrOCPlkgNN3JcypXC8R n8XMVgQmwGtjfjnYo0rPWkTUc2NC7Gl6VwnL81Ls5xpEC1luo1zU8slGuc10immxsdtu JNcFzQh18Ir6dS0dihf7wvrCt26CV9Ahov9KB98EGblqHgjIUtyj/JattOT6164t+gwQ HFNA== X-Received: by 10.50.102.99 with SMTP id fn3mr2018869igb.5.1386177479497; Wed, 04 Dec 2013 09:17:59 -0800 (PST) Received: from [172.19.131.154] ([12.130.127.16]) by mx.google.com with ESMTPSA id l7sm5221794igx.2.2013.12.04.09.17.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 09:17:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> Date: Wed, 4 Dec 2013 09:17:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 17:18:04 -0000 > Assume that an operator deploys a PITR. What policy can that operator = enforce to ensure that it is compensated for all (or even most) of the = traffic that it carries across that PITR? Through the same monetizing means it does today to attract any type of = traffic it wants to transit. Dino From farinacci@gmail.com Wed Dec 4 09:20:48 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F92E1AE313 for ; Wed, 4 Dec 2013 09:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8b-Oe2T_wbu for ; Wed, 4 Dec 2013 09:20:43 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D768D1AE312 for ; Wed, 4 Dec 2013 09:20:42 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id x13so27683693ief.10 for ; Wed, 04 Dec 2013 09:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KEhXjaZ3ghQRVywaou0jtgyptkxnqxGUqjXIhG7TPr4=; b=vtVp/ELlnMOE5GOn7Bnlrw1KYnkh2LT1c67wF53mwE0dXJM0CUdlSwHQaPz4bZdhnf qEHhgdi1Qa8TNf+2APV49a2PF6LBXLfOgxOfKw6oL8D7W3aZo46dxJOOAm3Z0piWBwJH XctBa173f3DkacWjud0ydJTSn5fmmZvyHKcCm+vOk2U7JSoQBGv/qTfNA3GGJ1kELbTM MqMP7fdrhusZLB06LABB+sWToGDgdYxwangpCl+iw165asry+b+RywU+J+CKjJ+t1Flf rgG99DnW4ZaUCIj3hsGPNSHlKDfWTPlqLE1s37efER/JFBH89EUMrM94U3WEZV1Y/OQP S+qA== X-Received: by 10.50.178.202 with SMTP id da10mr2023055igc.44.1386177639825; Wed, 04 Dec 2013 09:20:39 -0800 (PST) Received: from [172.19.131.154] ([12.130.127.16]) by mx.google.com with ESMTPSA id j16sm5209715igf.6.2013.12.04.09.20.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 09:20:39 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <529F5FFA.6000201@joelhalpern.com> Date: Wed, 4 Dec 2013 09:20:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 17:20:48 -0000 > A partial answer that has been suggested is that the oeprator who = deploys the PITR is an EID allocator rather than a conventional / = existing ISP. Unfortunately, if LISp succeeds it is not clear that the = compensation levels can match the increasing demand for traffic in the = critical periods. Yes, it could be an (MSP) Mapping Service Provider that is an allocator. = But since LISP will be a substrate it has, it can monetize other = services like mobility and multi-homing at lower OpEx than it can today = (that is lower OpEx for multi-homing today, there really is no seamless = roaming service available). Dino From rbonica@juniper.net Wed Dec 4 11:27:46 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC361AE171 for ; Wed, 4 Dec 2013 11:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRAh9V36T2vK for ; Wed, 4 Dec 2013 11:27:45 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C1FD31AE0F8 for ; Wed, 4 Dec 2013 11:27:44 -0800 (PST) Received: from mail133-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 19:27:41 +0000 Received: from mail133-va3 (localhost [127.0.0.1]) by mail133-va3-R.bigfish.com (Postfix) with ESMTP id 9374B3C0142; Wed, 4 Dec 2013 19:27:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hz8dhz1de098h1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail133-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(13464003)(377454003)(4396001)(83322001)(2656002)(85306002)(80976001)(74366001)(81342001)(19580405001)(81686001)(50986001)(77982001)(74316001)(74876001)(59766001)(1411001)(54356001)(53806001)(76482001)(81542001)(47976001)(81816001)(47736001)(19580395003)(56816005)(90146001)(49866001)(51856001)(74706001)(79102001)(63696002)(31966008)(54316002)(83072001)(77096001)(65816001)(80022001)(74502001)(66066001)(76576001)(46102001)(33646001)(56776001)(76796001)(87936001)(69226001)(87266001)(47446002)(74662001)(76786001)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail133-va3 (localhost.localdomain [127.0.0.1]) by mail133-va3 (MessageSwitch) id 138618525920394_9149; Wed, 4 Dec 2013 19:27:39 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.237]) by mail133-va3.bigfish.com (Postfix) with ESMTP id E29EBA0098; Wed, 4 Dec 2013 19:27:38 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 19:27:36 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 19:27:35 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.825.14; Wed, 4 Dec 2013 19:27:33 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Wed, 4 Dec 2013 19:27:33 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0wAAEI/IAAAjLDYA== Date: Wed, 4 Dec 2013 19:27:32 +0000 Message-ID: <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> In-Reply-To: <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 19:27:46 -0000 Hi Dino, Could you be a bit more explicit?=20 Please assume the following operator requirements: - In order to ensure the customer experience, an operator wants to attract = all traffic from the global Internet to LISP sites that it supports through= PITRs that it operates. - In order to maintain financial viability, that same operator does not wan= t to attract any traffic from the global Internet to LISP sites that it doe= s not support through PITRs that it operates. Do you agree that these are both valid requirements? If so, how can the ope= rator do this while advertising only large aggregates of the EID address bl= ock to the global Internet? = Ron > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Wednesday, December 04, 2013 12:18 PM > To: Ronald Bonica > Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list > list > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >=20 > > Assume that an operator deploys a PITR. What policy can that operator > enforce to ensure that it is compensated for all (or even most) of the > traffic that it carries across that PITR? >=20 > Through the same monetizing means it does today to attract any type of > traffic it wants to transit. >=20 > Dino >=20 >=20 From rbonica@juniper.net Wed Dec 4 12:04:01 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01891AE19E for ; Wed, 4 Dec 2013 12:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF3paWNK8QRy for ; Wed, 4 Dec 2013 12:03:58 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id C9E801ACCEE for ; Wed, 4 Dec 2013 12:03:57 -0800 (PST) Received: from mail110-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE007.bigfish.com (10.174.4.70) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 20:03:54 +0000 Received: from mail110-db8 (localhost [127.0.0.1]) by mail110-db8-R.bigfish.com (Postfix) with ESMTP id 25CCA3203AC; Wed, 4 Dec 2013 20:03:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail110-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51704005)(377454003)(13464003)(479174003)(24454002)(4396001)(2656002)(47736001)(87266001)(54316002)(85306002)(80976001)(74662001)(74366001)(15975445006)(85852002)(81342001)(56776001)(77982001)(59766001)(69226001)(19580395003)(50986001)(47976001)(49866001)(76796001)(33646001)(81816001)(87936001)(79102001)(46102001)(77096001)(66066001)(80022001)(76482001)(74316001)(54356001)(74876001)(74502001)(81542001)(83072001)(83322001)(31966008)(19580405001)(63696002)(81686001)(76576001)(51856001)(47446002)(76786001)(65816001)(74706001)(53806001)(90146001)(56816005)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail110-db8 (localhost.localdomain [127.0.0.1]) by mail110-db8 (MessageSwitch) id 1386187431575357_4382; Wed, 4 Dec 2013 20:03:51 +0000 (UTC) Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.243]) by mail110-db8.bigfish.com (Postfix) with ESMTP id 7DEBD1800BB; Wed, 4 Dec 2013 20:03:51 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 20:03:50 +0000 Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 20:03:50 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.825.14; Wed, 4 Dec 2013 20:03:47 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Wed, 4 Dec 2013 20:03:47 +0000 From: Ronald Bonica To: "Joel M. Halpern" , Dino Farinacci Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0wAAB5fAAABjOuYA== Date: Wed, 4 Dec 2013 20:03:47 +0000 Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> In-Reply-To: <529F5FFA.6000201@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 20:04:01 -0000 Hi Joel, In that model, assume that I obtain EID space from an EID allocator. At som= e point in the future, the PITR service that that EID allocator provides be= comes inadequate. What is my can I do? Are there competing EID allocators? If I go with a competing EID allocator,= do I have to renumber? Ron > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, December 04, 2013 12:02 PM > To: Ronald Bonica; Dino Farinacci > Cc: LISP mailing list list > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >=20 > A partial answer that has been suggested is that the oeprator who > deploys the PITR is an EID allocator rather than a conventional / > existing ISP. Unfortunately, if LISp succeeds it is not clear that the > compensation levels can match the increasing demand for traffic in the > critical periods. >=20 > Yours, > Joel >=20 > On 12/4/13 11:51 AM, Ronald Bonica wrote: > > Dino, > > > > I am not understanding your response. Let me ask the question another > way. > > > > Assume that an operator deploys a PITR. What policy can that operator > enforce to ensure that it is compensated for all (or even most) of the > traffic that it carries across that PITR? > > > > > > Ron > > > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farinacci@gmail.com] > >> Sent: Wednesday, December 04, 2013 11:44 AM > >> To: Ronald Bonica > >> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list > >> list > >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 > >> > >>> Luigi, > >>> > >>> Is this really what is going to happen? > >>> > >>> If a PITR announces the entire /32 into the global Internet, it > puts > >> itself on the forwarding path for the entire /32, and incurs the > cost > >> associated with transporting traffic towards every site in that /32. > >> This is supportable only if the PITR operator is somehow compensated > >> for carrying all of that traffic. > >> > >> But maybe only from a few sources. But if the /32 needs to be > divided > >> based on region, then maybe /40s could be advertised. But to the > >> point about "few sources", the more PITRs there are, the better the > >> load is shared. > >> > >> And I envision PITRs will be deployed on on-path boxes anyways. > Those > >> boxes right now can route to the entire Internet, they are called PE > >> boxes, are they not Ron? > >> > >>> Isn't it more likely that the PITR operator will advertise only > >> slices of the /32, with each of those slices being assigned to > either > >> its customers (from whom it collects revenue) or the customers of > >> other operators with whom it has made financial arrangements? > >> > >> No it won't be that way. EIDs are provider independent. If you do > >> what we suggest, we make no forward progress. > >> > >> Dino > >> > >>> > >>> Ron > >>> > >>> > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >> > >> > > > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > >=20 From acabello@ac.upc.edu Wed Dec 4 12:29:33 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3C1AE178 for ; Wed, 4 Dec 2013 12:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23a9OE_wzyee for ; Wed, 4 Dec 2013 12:29:28 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 56C241AE1A8 for ; Wed, 4 Dec 2013 12:29:27 -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 rB4KSx79017631; Wed, 4 Dec 2013 21:28:59 +0100 Received: from [192.168.0.200] (unknown [46.27.20.114]) by gw.ac.upc.edu (Postfix) with ESMTP id E39256B01C1; Wed, 4 Dec 2013 21:26:54 +0100 (CET) Message-ID: <529F9088.8060504@ac.upc.edu> Date: Wed, 04 Dec 2013 21:28:56 +0100 From: Albert Cabellos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Terry Manderson , LISP mailing list list References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070000080001030401070804" Subject: Re: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 20:29:33 -0000 This is a multi-part message in MIME format. --------------070000080001030401070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi I went through the document in detail and IMHO it is well structured and more importantly, it provides a complete and meticulous analysis of the security threats of LISP on a public deployment. Below you can find some comments: Regards Albert * Section 4.2->In addition to the attacks described in this section end-hosts behind an ITR could use the data-plane to overflow the ITR's Map-Cache by sending packets to non-popular EID prefixes (pretty much as a scan attack but with a different goal). In this scenario the xTR may evict entries from the map-cache that are popular (and in-use) and disrupt the normal operation of the network by forcing flows to miss. Florin will send a paper describing and analyzing in detail the attack and its impact on cache performance. * Section 4.3.2.1-->RFC6830 states (referring to LSB): "These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described inSection 6.3 ." To which extent this is a security threat? xTRs will not blindly trust LSB. * Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests, hence there is a limit on the amplification attack. * Section 4.3.2.3->Iīm having a hard time understanding this attack, even under attack, the ETR will reply with the "real nonce", at least once. Probably Iīm missing something. * Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent through the mapping system (not directly to the source RLOC), in this case the attack is still effective and involves the Mapping System, the Map-Server and the xTR (if operating in non-proxy mode). Editorial, please consider them suggestions, at the end it is a matter of taste of the writer/reader. > 1. Introduction > > The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. specified instead of defined? > The present document assesses the security level and identifies > security threats in the LISP specification if LISP is deployed in the > Internet (i.e., a public non-trustable environment). As a result of > the performed analysis, the document discusses the severity of the > threats and proposes recommendations to reach the same level of > security in LISP than in Internet today (e.g., without LISP). "(i.e., without LISP)" (not e.g.,) I understand that the authors are not referring to an example. > This document does not consider all the possible uses of LISP as > discussed in [RFC6830]. The document focuses on LISP unicast, > including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and > LISP Map-Versioning [RFC6834]. The reading of these documents is a > prerequisite for understanding the present document. Several deployment scenarios are discussed in draft-ietf-lisp-deployment, please consider citing it and discussing if the use-cases described in the deployment draft are covered by this analysis. > SA is an off-path attacker that is able to send spoofed packets, > i.e., packets with a different source IP address than its > assigned IP address. SA stands for Spoofing Attacker. SA attackers need access to the RLOC space, it might make sense to state this here. > 4.3.1.2. Threats concerning Interworking > > [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow Edit "and" instead of "And" On 02/12/2013 3:02, Terry Manderson wrote: > I would just like to highlight that the end of this LC draws near. > > Without review, this document cannot move forward. > > Cheers > Terry > > On 20/11/13 9:23 AM, "Terry Manderson" wrote: > >> All, >> >> As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have >> requested a work group last call. >> >> Here starts a 14 day last call for this document, the last call will end >> on >> Wednesday 4th December 2013. >> >> You will find its text here: >> http://tools.ietf.org/html/draft-ietf-lisp-threats-08 >> >> Please review this WG item and provide any last comments. >> >> Cheers >> Terry >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp --------------070000080001030401070804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

I went through the document in detail and IMHO it is well structured and
more importantly, it provides a complete and meticulous analysis of the
security threats of LISP on a public deployment.
Below you can find some comments:

Regards

Albert


* Section 4.2->In addition to the attacks described in this section
end-hosts behind an ITR could use the data-plane to overflow the ITR's
Map-Cache by sending packets to non-popular EID prefixes (pretty much as
a scan attack but with a different goal). In this scenario the xTR may
evict entries from the map-cache that are popular (and in-use) and disrupt the normal
operation of the network by forcing flows to miss. Florin will send a paper describing and analyzing
in detail the attack and its impact on cache performance.

* Section 4.3.2.1-->RFC6830 states (referring to LSB):

"These bits are used as
      a hint to convey up/down router status and not path reachability
      status.  The LSBs can be verified by use of one of the Locator
      reachability algorithms described inSection 6.3
<http://tools.ietf.org/html/rfc6830#section-6.3>."

To which extent this is a security threat? xTRs will not blindly trust LSB.


* Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.


* Section 4.3.2.3->I´m having a hard time understanding this attack,
even under attack, the ETR will reply with the "real nonce", at least
once. Probably I´m missing something.


* Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent
through the mapping system (not directly to the source RLOC), in this
case the attack is still effective and involves the Mapping System, the
Map-Server and the xTR (if operating in non-proxy mode).

Editorial, please consider them suggestions, at the end it is a matter
of taste of the writer/reader.

> 1.  Introduction
>
>    The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].

specified instead of defined?

>    The present document assesses the security level and identifies
>    security threats in the LISP specification if LISP is deployed in the
>    Internet (i.e., a public non-trustable environment).  As a result of
>    the performed analysis, the document discusses the severity of the
>    threats and proposes recommendations to reach the same level of
>    security in LISP than in Internet today (e.g., without LISP).

"(i.e., without LISP)" (not e.g.,) I understand that the authors are not
referring to an example.

>    This document does not consider all the possible uses of LISP as
>    discussed in [RFC6830].  The document focuses on LISP unicast,
>    including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and
>    LISP Map-Versioning [RFC6834].  The reading of these documents is a
>    prerequisite for understanding the present document.

Several deployment scenarios are discussed in
draft-ietf-lisp-deployment, please consider citing it and discussing if
the use-cases described in the deployment draft are covered by this
analysis.

>    SA  is an off-path attacker that is able to send spoofed packets,
>        i.e., packets with a different source IP address than its
>        assigned IP address.  SA stands for Spoofing Attacker.

SA attackers need access to the RLOC space, it might make sense to state
this here.

> 4.3.1.2.  Threats concerning Interworking
>
>    [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow

Edit "and" instead of "And"

On 02/12/2013 3:02, Terry Manderson wrote:
I would just like to highlight that the end of this LC draws near.

Without review, this document cannot move forward.

Cheers
Terry

On 20/11/13 9:23 AM, "Terry Manderson" <terry.manderson@icann.org> wrote:


All,

As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have
requested a work group last call.

Here starts a 14 day last call for this document, the last call will end
on
Wednesday 4th December 2013.

You will find its text here:
http://tools.ietf.org/html/draft-ietf-lisp-threats-08

Please review this WG item and provide any last comments.

Cheers
Terry



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

--------------070000080001030401070804-- From gih@apnic.net Wed Dec 4 13:21:46 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1EC1AE131 for ; Wed, 4 Dec 2013 13:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.798 X-Spam-Level: X-Spam-Status: No, score=-100.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-S4TbIPEcQG for ; Wed, 4 Dec 2013 13:21:45 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [203.119.98.120]) by ietfa.amsl.com (Postfix) with SMTP id 819161AD94A for ; Wed, 4 Dec 2013 13:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=SzwDNw68ckr2ZQiMOM4xyQAnyVVR9qAn+hlZdcgxHrU=; b=h9V7bIYFb8zUeYsyYye7OuptGKKKIL/qezuzTyf6NTTED90xNcyG/E3cO0HqYLk8fDSS7c08u7teX b1W2GHmv33fbv6YkRObkl31vDWnGjZN8dU2M4erM6Yf79w3tAG67V2f8ZRiWnVjdDPq3Rhs7SQ92NB ivUJ5rODUBcSa8vw= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 5 Dec 2013 07:15:14 +1000 (EST) Received: from [203.119.42.9] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 5 Dec 2013 07:15:19 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Geoff Huston In-Reply-To: <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> Date: Thu, 5 Dec 2013 08:15:18 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <7399594F-0E68-4965-B69D-F6F07A40DE1D@apnic.net> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 21:21:46 -0000 I don't think its quite as simple as that Ron. If the role of a service = provider is to provide service to its customers then an ISP with a LISP = interface may advertise the entire LISP prefix to its global unicast = non-LISP customers, but no further. This is in addition to your = consideration that the ISP would conventionally want to advertise the = specific LISP prefixes of its customers to the larger inter-domain = routing space. This is comparable to conventional routing theology: you = advertise default to your customers and advertise your customers' = specific routes to the world at large. We tried this with a similar experiment with 2002::/16 some years back. = It was not a blinding success, but maybe there are lessons to be learnt = from that experience. Geoff On 5 Dec 2013, at 6:27 am, Ronald Bonica wrote: > Hi Dino, >=20 > Could you be a bit more explicit?=20 >=20 > Please assume the following operator requirements: >=20 > - In order to ensure the customer experience, an operator wants to = attract all traffic from the global Internet to LISP sites that it = supports through PITRs that it operates. > - In order to maintain financial viability, that same operator does = not want to attract any traffic from the global Internet to LISP sites = that it does not support through PITRs that it operates. >=20 > Do you agree that these are both valid requirements? If so, how can = the operator do this while advertising only large aggregates of the EID = address block to the global Internet? >=20 > = Ron >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, December 04, 2013 12:18 PM >> To: Ronald Bonica >> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list >> list >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>=20 >>> Assume that an operator deploys a PITR. What policy can that = operator >> enforce to ensure that it is compensated for all (or even most) of = the >> traffic that it carries across that PITR? >>=20 >> Through the same monetizing means it does today to attract any type = of >> traffic it wants to transit. >>=20 >> Dino >>=20 >>=20 >=20 >=20 From damien.saucez@gmail.com Wed Dec 4 13:41:05 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30531AE1F9 for ; Wed, 4 Dec 2013 13:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGYJ6OYS-joO for ; Wed, 4 Dec 2013 13:41:01 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 225C21ACC81 for ; Wed, 4 Dec 2013 13:41:00 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so10081758wes.17 for ; Wed, 04 Dec 2013 13:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=T9Ub6LKU35SgrttjoWqjTWsX8MBB5Vb36rpk4mXh3Q4=; b=BkYCUBpryEv0Si41d2J9zkjvvMDugzDsLdhFsSAza5CCpYYWRM38pNQHvk6wWSpEa0 oRT1ayhbjrQE5TrxYlCZftGHVo4/gvGkxyJ6bF/uhUln0lLa4q7su3UWLPcmJfOkzX+7 7M+NlqCHXDlLMJ/L5QQWSqPKBUCnpVE2Z0TXfk4ngU9OU1rpbF1C5bZsjSM3NKI6DyBV Hx0gnnKqaP9IY0yM+9bie2ivVQgmsNlW7TztkfPEqNU/a/prJ7lAeAZy1RkmXa8Mi8Iv AXct9RQ7jX0pQq/dii/zWUVT3m7rufaWmxRvnoq/O5jfWJNfGzyFHTlfRwLU+nmEGbDL F2Yw== X-Received: by 10.194.104.66 with SMTP id gc2mr4185289wjb.75.1386193257544; Wed, 04 Dec 2013 13:40:57 -0800 (PST) Received: from [192.168.1.136] (LVelizy-156-46-22-251.w80-11.abo.wanadoo.fr. [80.11.231.251]) by mx.google.com with ESMTPSA id s20sm10745551wib.1.2013.12.04.13.40.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 13:40:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A474E50-EAD4-4392-9F58-1A7DB75C869B" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Damien Saucez In-Reply-To: <529F9088.8060504@ac.upc.edu> Date: Wed, 4 Dec 2013 22:40:54 +0100 Message-Id: <91805CE8-01CC-4F6D-945F-D98D23A3F179@gmail.com> References: <529F9088.8060504@ac.upc.edu> To: Albert Cabellos X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 21:41:06 -0000 --Apple-Mail=_2A474E50-EAD4-4392-9F58-1A7DB75C869B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Albert, On 04 Dec 2013, at 21:28, Albert Cabellos wrote: > Hi >=20 > I went through the document in detail and IMHO it is well structured = and=20 > more importantly, it provides a complete and meticulous analysis of = the=20 > security threats of LISP on a public deployment.=20 Thank you for the review Albert. > Below you can find some comments: >=20 My answers inline. > Regards >=20 > Albert >=20 >=20 > * Section 4.2->In addition to the attacks described in this section > end-hosts behind an ITR could use the data-plane to overflow the ITR's > Map-Cache by sending packets to non-popular EID prefixes (pretty much = as > a scan attack but with a different goal). In this scenario the xTR may > evict entries from the map-cache that are popular (and in-use) and = disrupt the normal > operation of the network by forcing flows to miss. Florin will send a = paper describing and analyzing > in detail the attack and its impact on cache performance. >=20 ok > * Section 4.3.2.1-->RFC6830 states (referring to LSB): >=20 > "These bits are used as > a hint to convey up/down router status and not path reachability > status. The LSBs can be verified by use of one of the Locator > reachability algorithms described inSection 6.3=20 > ." >=20 > To which extent this is a security threat? xTRs will not blindly trust = LSB. >=20 >=20 actually it is not a MUST not even a SHOULD in RFC6830 so it is important to emphasis on the risk. > * Section 4.3.2.2->RFC6830 already recommends rate-limiting = Map-Requests, > hence there is a limit on the amplification attack. >=20 I think the analysis is complementary to the recommendation. In RFC6830, no reason is given about why rate limit, here it shows why this is recommended. >=20 > * Section 4.3.2.3->I=B4m having a hard time understanding this attack, > even under attack, the ETR will reply with the "real nonce", at least > once. Probably I=B4m missing something. >=20 >=20 sure but if an attacker floods with random nonce, then when the node will answer with the real nonce, it will already have been changed to another one sent by the attacker. > * Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent > through the mapping system (not directly to the source RLOC), in this > case the attack is still effective and involves the Mapping System, = the > Map-Server and the xTR (if operating in non-proxy mode). >=20 I am not sure I understand your question here. > Editorial, please consider them suggestions, at the end it is a matter > of taste of the writer/reader. ok, will take them into account according to other reviews. > > 1. Introduction > > > > The Locator/ID Separation Protocol (LISP) is defined in = [RFC6830]. >=20 > specified instead of defined? >=20 > > The present document assesses the security level and identifies > > security threats in the LISP specification if LISP is deployed in = the > > Internet (i.e., a public non-trustable environment). As a result = of > > the performed analysis, the document discusses the severity of = the > > threats and proposes recommendations to reach the same level of > > security in LISP than in Internet today (e.g., without LISP). >=20 > "(i.e., without LISP)" (not e.g.,) I understand that the authors are = not > referring to an example. >=20 > > This document does not consider all the possible uses of LISP as > > discussed in [RFC6830]. The document focuses on LISP unicast, > > including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], = and > > LISP Map-Versioning [RFC6834]. The reading of these documents is = a > > prerequisite for understanding the present document. >=20 > Several deployment scenarios are discussed in > draft-ietf-lisp-deployment, please consider citing it and discussing = if > the use-cases described in the deployment draft are covered by this > analysis. >=20 > > SA is an off-path attacker that is able to send spoofed packets, > > i.e., packets with a different source IP address than its > > assigned IP address. SA stands for Spoofing Attacker. >=20 > SA attackers need access to the RLOC space, it might make sense to = state > this here. >=20 > > 4.3.1.2. Threats concerning Interworking > > > > [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to = allow >=20 > Edit "and" instead of "And" >=20 > On 02/12/2013 3:02, Terry Manderson wrote: >> I would just like to highlight that the end of this LC draws near. >>=20 >> Without review, this document cannot move forward. >>=20 >> Cheers >> Terry >>=20 >> On 20/11/13 9:23 AM, "Terry Manderson" = wrote: >>=20 >>> All, >>>=20 >>> As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 = have >>> requested a work group last call. >>>=20 >>> Here starts a 14 day last call for this document, the last call will = end >>> on >>> Wednesday 4th December 2013. >>>=20 >>> You will find its text here: >>> http://tools.ietf.org/html/draft-ietf-lisp-threats-08 >>>=20 >>> Please review this WG item and provide any last comments. >>>=20 >>> Cheers >>> Terry >>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_2A474E50-EAD4-4392-9F58-1A7DB75C869B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = Albert,

On 04 Dec 2013, at 21:28, Albert Cabellos = <acabello@ac.upc.edu> = wrote:

=20 =20
Hi

I went through the document in detail and IMHO it is well structured and
more importantly, it provides a complete and meticulous analysis of the
security threats of LISP on a public deployment. =

Thank you for the review = Albert.

Below you can find some comments:


My answers = inline.

Regards

Albert


* Section 4.2->In addition to the attacks described in this section
end-hosts behind an ITR could use the data-plane to overflow the ITR's
Map-Cache by sending packets to non-popular EID prefixes (pretty much as
a scan attack but with a different goal). In this scenario the xTR may
evict entries from the map-cache that are popular (and in-use) and disrupt the normal
operation of the network by forcing flows to miss. Florin will send a paper describing and analyzing
in detail the attack and its impact on cache performance.


ok

* Section 4.3.2.1-->RFC6830 states (referring to LSB):

"These bits are used as
      a hint to convey up/down router = status and not path reachability
      status.  The LSBs can be = verified by use of one of the Locator
      reachability algorithms described = inSection 6.3
<http://tools.i= etf.org/html/rfc6830#section-6.3>."

To which extent this is a security threat? xTRs will not blindly trust LSB.



actually it is not a MUST = not even a SHOULD in RFC6830 so it is
important to emphasis on = the risk.

* Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.


I think the analysis = is complementary to the recommendation.  In
RFC6830, no = reason is given about why rate limit, here it shows why
this = is recommended.


* Section 4.3.2.3->I=B4m having a hard time understanding this attack,
even under attack, the ETR will reply with the "real nonce", at least
once. Probably I=B4m missing something.



sure but if an = attacker floods with random nonce, then when the node
will = answer with the real nonce, it will already have been changed = to
another one sent by the = attacker.

* Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent
through the mapping system (not directly to the source RLOC), in this
case the attack is still effective and involves the Mapping System, the
Map-Server and the xTR (if operating in non-proxy mode).


I am not sure I understand = your question here.


Editorial, please consider them suggestions, at the end it is a matter
of taste of the = writer/reader.

ok, will take = them into account according to other reviews.

> 1.  Introduction
>
>    The Locator/ID Separation Protocol (LISP) is = defined in [RFC6830].

specified instead of defined?

>    The present document assesses the security = level and identifies
>    security threats in the LISP specification if = LISP is deployed in the
>    Internet (i.e., a public non-trustable = environment).  As a result of
>    the performed analysis, the document = discusses the severity of the
>    threats and proposes recommendations to reach = the same level of
>    security in LISP than in Internet today = (e.g., without LISP).

"(i.e., without LISP)" (not e.g.,) I understand that the authors are not
referring to an example.

>    This document does not consider all the = possible uses of LISP as
>    discussed in [RFC6830].  The document = focuses on LISP unicast,
>    including as well LISP Interworking = [RFC6832], LISP-MS [RFC6833], and
>    LISP Map-Versioning [RFC6834].  The = reading of these documents is a
>    prerequisite for understanding the present = document.

Several deployment scenarios are discussed in
draft-ietf-lisp-deployment, please consider citing it and discussing if
the use-cases described in the deployment draft are covered by = this
analysis.

>    SA  is an off-path attacker that is able = to send spoofed packets,
>        i.e., packets with a = different source IP address than its
>        assigned IP = address.  SA stands for Spoofing Attacker.

SA attackers need access to the RLOC space, it might make sense to state
this here.

> 4.3.1.2.  Threats concerning Interworking
>
>    [RFC6832] defines Proxy-ITR And Proxy-ETR = network elements to allow

Edit "and" instead of "And"

On 02/12/2013 3:02, Terry Manderson wrote:
I would just like to highlight that the end of this =
LC draws near.

Without review, this document cannot move forward.

Cheers
Terry

On 20/11/13 9:23 AM, "Terry Manderson" <terry.manderson@icann.org>=
; wrote:


All,

As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 =
have
requested a work group last call.

Here starts a 14 day last call for this document, the last call will end
on
Wednesday 4th December 2013.

You will find its text here:
http://tool=
s.ietf.org/html/draft-ietf-lisp-threats-08

Please review this WG item and provide any last comments.

Cheers
Terry



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

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

= --Apple-Mail=_2A474E50-EAD4-4392-9F58-1A7DB75C869B-- From rbonica@juniper.net Wed Dec 4 14:34:55 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FFC1AE151 for ; Wed, 4 Dec 2013 14:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmA0QPR9sPjP for ; Wed, 4 Dec 2013 14:34:52 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id AEDD31AE131 for ; Wed, 4 Dec 2013 14:34:52 -0800 (PST) Received: from mail75-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE020.bigfish.com (10.236.130.83) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 22:34:49 +0000 Received: from mail75-co9 (localhost [127.0.0.1]) by mail75-co9-R.bigfish.com (Postfix) with ESMTP id F0AE116008B; Wed, 4 Dec 2013 22:34:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail75-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51704005)(4396001)(2656002)(47736001)(87266001)(54316002)(85306002)(74662001)(80976001)(74366001)(85852002)(81342001)(77982001)(56776001)(59766001)(69226001)(47976001)(50986001)(49866001)(76796001)(33646001)(87936001)(79102001)(46102001)(66066001)(77096001)(81816001)(80022001)(76482001)(74316001)(54356001)(74876001)(74502001)(83072001)(81542001)(83322001)(31966008)(63696002)(81686001)(76576001)(51856001)(47446002)(76786001)(65816001)(53806001)(74706001)(90146001)(56816005)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.18; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail75-co9 (localhost.localdomain [127.0.0.1]) by mail75-co9 (MessageSwitch) id 1386196486550974_19488; Wed, 4 Dec 2013 22:34:46 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.239]) by mail75-co9.bigfish.com (Postfix) with ESMTP id 81E0B3E0031; Wed, 4 Dec 2013 22:34:46 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 22:34:46 +0000 Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 22:34:40 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.825.14; Wed, 4 Dec 2013 22:34:38 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Wed, 4 Dec 2013 22:34:38 +0000 From: Ronald Bonica To: Geoff Huston Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0wAAEI/IAAAjLDYAAGGIEAAAIM20A= Date: Wed, 4 Dec 2013 22:34:37 +0000 Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <7399594F-0E68-4965-B69D-F6F07A40DE1D@apnic.net> In-Reply-To: <7399594F-0E68-4965-B69D-F6F07A40DE1D@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.18] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 04 Dec 2013 22:34:55 -0000 >=20 > I don't think its quite as simple as that Ron. If the role of a service > provider is to provide service to its customers then an ISP with a LISP > interface may advertise the entire LISP prefix to its global unicast > non-LISP customers, but no further.=20 Is this really how it works? If so, how would someone connected to an ISP t= hat does not deploy a PITR access a LISP site? Ron P.S. It would be great if we could nail down some of these details. For ins= tance, who is expected to operate the PITR, the EID allocator (as Joel sugg= ests) or the ISP (as you suggest). Who is expected to advertise which route= s. Until we understand this, it is impossible to have an intelligent conver= sation and probably premature to make an address block allocation. From gih@apnic.net Wed Dec 4 16:20:10 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D939A1AE1A9 for ; Wed, 4 Dec 2013 16:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAyw1lMCWXCu for ; Wed, 4 Dec 2013 16:20:08 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 452DF1AE195 for ; Wed, 4 Dec 2013 16:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:content-type:mime-version:subject:from:in-reply-to: date:cc:content-transfer-encoding:message-id:references:to:x-mailer: return-path; bh=vVn/iPAuOgik6PTkQG9bTKO0FTVOeWamRouwXYxbz88=; b=T7+O2WtobYDO+H0IvDQUSYSB01MWm9az8bm89xST/hqr21S1Y/Y0DYOng81ypMVS0MqhvQnR7rQce dbNnMyApYDTKuuH5Wmk+ZOo0EqyAQclvKgy4zTtZzm3PrU/vupfxn4kD8WbScm6wwEyKXfxxNp6jXY L0fukTwlKmtvCLOg= Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 5 Dec 2013 10:20:03 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by IAMDA1.org.apnic.net (2001:dd8:a:852::11) with Microsoft SMTP Server (TLS) id 14.1.421.2; Thu, 5 Dec 2013 10:20:03 +1000 Received: from [203.119.42.9] (203.119.101.249) by IAMDA2.org.apnic.net (203.119.111.21) with Microsoft SMTP Server (TLS) id 14.1.438.0; Thu, 5 Dec 2013 10:20:03 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Geoff Huston In-Reply-To: Date: Thu, 5 Dec 2013 11:20:02 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <7399594F-0E68-4965-B69D-F6F07A40DE1D@apnic.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 00:20:11 -0000 On 5 Dec 2013, at 9:34 am, Ronald Bonica wrote: >>=20 >> I don't think its quite as simple as that Ron. If the role of a = service >> provider is to provide service to its customers then an ISP with a = LISP >> interface may advertise the entire LISP prefix to its global unicast >> non-LISP customers, but no further.=20 >=20 > Is this really how it works? If so, how would someone connected to an = ISP that does not deploy a PITR access a LISP site? >=20 Our experience with piecemeal advertisements of 2002::/16 points to an = answer that says that such folk as you describe here are then reliant on = the kindness of strangers, or alternatively things are broken for them, = or even both. > P.S. It would be great if we could nail down some of these details. = For instance, who is expected to operate the PITR, the EID allocator (as = Joel suggests) or the ISP (as you suggest). Who is expected to advertise = which routes. Until we understand this, it is impossible to have an = intelligent conversation and probably premature to make an address block = allocation. I'm not sure I agree Ron - the prospect of the allocation has teased out = this matter, and it has made an otherwise abstract conversation into one = that probably needs some level of timely resolution, if we can. If we = can clarify the draft even in terms of expectation of routing behaviour = I think that we would have done enough for an experimental allocation = context at this point in time. Geoff From pvinci@VinciConsulting.com Wed Dec 4 19:39:38 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6911AE171 for ; Wed, 4 Dec 2013 19:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo_fWXQez2bY for ; Wed, 4 Dec 2013 19:39:36 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id C77221AE140 for ; Wed, 4 Dec 2013 19:39:35 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0342.003; Wed, 4 Dec 2013 22:34:21 -0500 From: Paul Vinciguerra To: Ronald Bonica , Dino Farinacci Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegChZC2AABscEYAACyoyAAA2EAyAACUTvoAAArprAAAAPryAAADrvIAABIfCAAAFh0HT Date: Thu, 5 Dec 2013 03:34:07 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807CB1A978F0@NYDC-EXCH01.vinci-consulting-corp.local> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com>, <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.199.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 03:39:38 -0000 Ron,=0A= =0A= I think that Dino is suggesting that ISP's with their own populations deplo= y PITRs for this /32 prefix and announce the /32 into BGP with a no-export = community, so that you as an ISP provide encapsulation as close to source o= f your customer population only. This will (1) save you transit costs to a= nother PITR provider for this prefix. You would only be paying for transit = if the RLOC were not on your network. where otherwise you might be paying f= or transit between two of your customers. (2) it will give your customers a= n optimal path because you are encapsulating close to the source. and this = will (3) allow for PITR Gateways to be deployed on smaller equipment.=0A= =0A= Also, this would not stop a given EID who wants to have global reachability= from a given PITR gateway system from buying "EID Transit" from a PITR pro= vider who will announce the more specific EID prefix out of the /32 for a p= rice. I don't know that announcing a more specific globally is a great ide= a, though. It actually could cause traffic to take a less direct path. = =0A= =0A= Paul=0A= ________________________________________=0A= From: lisp [lisp-bounces@ietf.org] on behalf of Ronald Bonica [rbonica@juni= per.net]=0A= Sent: Wednesday, December 04, 2013 2:27 PM=0A= To: Dino Farinacci=0A= Cc: LISP mailing list list=0A= Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07=0A= =0A= Hi Dino,=0A= =0A= Could you be a bit more explicit?=0A= =0A= Please assume the following operator requirements:=0A= =0A= - In order to ensure the customer experience, an operator wants to attract = all traffic from the global Internet to LISP sites that it supports through= PITRs that it operates.=0A= - In order to maintain financial viability, that same operator does not wan= t to attract any traffic from the global Internet to LISP sites that it doe= s not support through PITRs that it operates.=0A= =0A= Do you agree that these are both valid requirements? If so, how can the ope= rator do this while advertising only large aggregates of the EID address bl= ock to the global Internet?=0A= =0A= = Ron=0A= =0A= > -----Original Message-----=0A= > From: Dino Farinacci [mailto:farinacci@gmail.com]=0A= > Sent: Wednesday, December 04, 2013 12:18 PM=0A= > To: Ronald Bonica=0A= > Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list=0A= > list=0A= > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07=0A= >=0A= > > Assume that an operator deploys a PITR. What policy can that operator= =0A= > enforce to ensure that it is compensated for all (or even most) of the=0A= > traffic that it carries across that PITR?=0A= >=0A= > Through the same monetizing means it does today to attract any type of=0A= > traffic it wants to transit.=0A= >=0A= > Dino=0A= >=0A= >=0A= =0A= =0A= _______________________________________________=0A= lisp mailing list=0A= lisp@ietf.org=0A= https://www.ietf.org/mailman/listinfo/lisp=0A= From farinacci@gmail.com Wed Dec 4 20:24:45 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB51AE1B2 for ; Wed, 4 Dec 2013 20:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkXjxArO560K for ; Wed, 4 Dec 2013 20:24:43 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CA7E41AE1A7 for ; Wed, 4 Dec 2013 20:24:43 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id rq2so24920983pbb.2 for ; Wed, 04 Dec 2013 20:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hPTV3VJcLLZBKN0KpAbiOGeEkBs/JgC5WBtsspk09Rw=; b=sagoIaWUphaywLBPK8RuqLnmfll8TE/wUOUSU0/edpgBm7elTzqrmDoUqWG96tYVzz i5ZWzvyKEtcUFGUq/W6UpBd/9aZEb/5pM99xxnjKgd8DLdJ+04fPnNGpid1wV7+Z+Xfs LmyeTrPEg2AmY7Le0pSvVqQlxQDqcMgQbs49OqS2qb7HXts1KX2oJlQGmJga9yFf1t+2 XdDuxb5Bpa9x+Sh6/qpINhdYV81awYvdRJC4dqgRwmy4guWVaC8p3Rm8Oh/80ZRn9vaJ 6zOzoIo3EKH4x6tkSS/jHFy7YB8E9ktZGAeQWPxZNEsIoaal35dz4kd7/oLXRuk+9LyC p5+A== X-Received: by 10.66.219.233 with SMTP id pr9mr86033852pac.45.1386217480602; Wed, 04 Dec 2013 20:24:40 -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 ESMTPSA id iu7sm141227324pbc.45.2013.12.04.20.24.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 20:24:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> Date: Wed, 4 Dec 2013 20:24:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 04:24:46 -0000 > - In order to ensure the customer experience, an operator wants to = attract all traffic from the global Internet to LISP sites that it = supports through PITRs that it operates. That would create a bad customer experience. > - In order to maintain financial viability, that same operator does = not want to attract any traffic from the global Internet to LISP sites = that it does not support through PITRs that it operates. It certainly does if its customers are LISP sites. > Do you agree that these are both valid requirements? If so, how can = the operator do this while advertising only large aggregates of the EID = address block to the global Internet? No, I don't agree. As I said before, the /32 advertisements of an EID-block are advertised = within an ISP towards the edges of the network. Those edges are towards = its customers so its customers, as sources in non-LISP sites, can reach = destinations in LISP sites. Dino From farinacci@gmail.com Wed Dec 4 20:26:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523921AE1B2 for ; Wed, 4 Dec 2013 20:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHb5mpVngiys for ; Wed, 4 Dec 2013 20:26:02 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8881AE1A7 for ; Wed, 4 Dec 2013 20:26:01 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so24979318pbb.18 for ; Wed, 04 Dec 2013 20:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0Cs6atZNyIojGt5+mdfDIBkpagjlyRjtn1ZUetyYXmI=; b=HKszwLrs5u/VDs10ybjB/ThUjjJe4ddAm62lqhAB9gUuOhcmY72eE9iLvW5sRBKxQb 3WwtlTHmgy5IkJLmGUSxnBNXnmeQQ+pGnAx/V0XRSvtK/k3uSyxWmFR2poj0NH6RHm1q 3F+R5ug+oUHzwCGM9Rn3jNFwUWR4O+U2CDJ9srypUz1vAs1B8mxOQcHGSx+oYKekNnTV 8nvpzRCO5TJatyxiK37iljdlKRsLVNhSVveUig43adRK5cvfASluNmvh5t8j67uqZusg fdDqC66ZmzfYZNQdOp+J6wi5FB8w28TDV6U8YmbbWwU4PJKcT/X+Kr1uQ/eqCNVdFRjc rwgQ== X-Received: by 10.68.197.104 with SMTP id it8mr50043989pbc.17.1386217550790; Wed, 04 Dec 2013 20:25:50 -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 ESMTPSA id sy10sm162763283pac.15.2013.12.04.20.25.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 20:25:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <7399594F-0E68-4965-B69D-F6F07A40DE1D@apnic.net> Date: Wed, 4 Dec 2013 20:25:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <45A58D3E-AD9A-4DB6-87EB-285F97A78336@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <7399594F-0E68-4965-B69D-F6F07A40DE1D@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 04:26:04 -0000 Exactly. Dino On Dec 4, 2013, at 1:15 PM, Geoff Huston wrote: > I don't think its quite as simple as that Ron. If the role of a = service provider is to provide service to its customers then an ISP with = a LISP interface may advertise the entire LISP prefix to its global = unicast non-LISP customers, but no further. This is in addition to your = consideration that the ISP would conventionally want to advertise the = specific LISP prefixes of its customers to the larger inter-domain = routing space. This is comparable to conventional routing theology: you = advertise default to your customers and advertise your customers' = specific routes to the world at large. >=20 > We tried this with a similar experiment with 2002::/16 some years = back. It was not a blinding success, but maybe there are lessons to be = learnt from that experience. >=20 > Geoff >=20 >=20 > On 5 Dec 2013, at 6:27 am, Ronald Bonica wrote: >=20 >> Hi Dino, >>=20 >> Could you be a bit more explicit?=20 >>=20 >> Please assume the following operator requirements: >>=20 >> - In order to ensure the customer experience, an operator wants to = attract all traffic from the global Internet to LISP sites that it = supports through PITRs that it operates. >> - In order to maintain financial viability, that same operator does = not want to attract any traffic from the global Internet to LISP sites = that it does not support through PITRs that it operates. >>=20 >> Do you agree that these are both valid requirements? If so, how can = the operator do this while advertising only large aggregates of the EID = address block to the global Internet? >>=20 >> = Ron >>=20 >>> -----Original Message----- >>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>> Sent: Wednesday, December 04, 2013 12:18 PM >>> To: Ronald Bonica >>> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list >>> list >>> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>>=20 >>>> Assume that an operator deploys a PITR. What policy can that = operator >>> enforce to ensure that it is compensated for all (or even most) of = the >>> traffic that it carries across that PITR? >>>=20 >>> Through the same monetizing means it does today to attract any type = of >>> traffic it wants to transit. >>>=20 >>> Dino >>>=20 >>>=20 >>=20 >>=20 >=20 From farinacci@gmail.com Wed Dec 4 20:27:25 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1C1ADF5A for ; Wed, 4 Dec 2013 20:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5s0cweSPlwP for ; Wed, 4 Dec 2013 20:27:22 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id ADE8F1AD986 for ; Wed, 4 Dec 2013 20:27:22 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id r10so23712439pdi.24 for ; Wed, 04 Dec 2013 20:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vOAur16fxoz+NXpwzb/naOK5a/I2OKlnFxXu9c+n3/M=; b=iiqBhePq45QKR/EBS+3Tb84c9tkBubYHyl9Q5yzuvDDsJMbVkLKJ2d1av5aZQCjDlR c8e5bu1m4rZ5sjv8hSKJemniK+kOZPak3k7sqGTE/92uThdgNzQx6pmCHwP7QScnnCG1 VBWxrtW6ijcuYCurDqpZ9sX19zQZbbZtXcJyIdNWznP1nYmAnBE95eIcJmj5byPOl/Kj +jZlSDfY6iojQ0cxQU1Q8JvksWUUVo5nvIhFyr3+D2rh7M105fBfsSn9QSqLyGVnUPrl eagHvX3jBaVlkpTTKfGxjSeWTGvFHA4XiqJRGVwrSM8pRkMLF9r0zmhknRcZp7SP49pA n1lg== X-Received: by 10.68.134.98 with SMTP id pj2mr49816356pbb.110.1386217639304; Wed, 04 Dec 2013 20:27:19 -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 ESMTPSA id uf2sm141254928pbc.28.2013.12.04.20.27.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 20:27:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <6E5736BD68F770449C74FBAD975F807CB1A978F0@NYDC-EXCH01.vinci-consulting-corp.local> Date: Wed, 4 Dec 2013 20:27:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1A46118C-E911-450F-A076-9513173E59DC@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com>, <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <6E5736BD68F770449C74FBAD975F807CB1A978F0@NYDC-EXCH01.vinci-consulting-corp.local> To: Paul Vinciguerra X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 04:27:25 -0000 Exactly. And arguably the closer the the ISP PITRs are to its customer = sources, it may be on their default path so maybe the /32 doesn't need = to be advertised at all. Dino On Dec 4, 2013, at 7:34 PM, Paul Vinciguerra = wrote: > Ron, >=20 > I think that Dino is suggesting that ISP's with their own populations = deploy PITRs for this /32 prefix and announce the /32 into BGP with a = no-export community, so that you as an ISP provide encapsulation as = close to source of your customer population only. This will (1) save = you transit costs to another PITR provider for this prefix. You would = only be paying for transit if the RLOC were not on your network. where = otherwise you might be paying for transit between two of your customers. = (2) it will give your customers an optimal path because you are = encapsulating close to the source. and this will (3) allow for PITR = Gateways to be deployed on smaller equipment. >=20 > Also, this would not stop a given EID who wants to have global = reachability from a given PITR gateway system from buying "EID Transit" = from a PITR provider who will announce the more specific EID prefix out = of the /32 for a price. I don't know that announcing a more specific = globally is a great idea, though. It actually could cause traffic to = take a less direct path. =20 >=20 > Paul > ________________________________________ > From: lisp [lisp-bounces@ietf.org] on behalf of Ronald Bonica = [rbonica@juniper.net] > Sent: Wednesday, December 04, 2013 2:27 PM > To: Dino Farinacci > Cc: LISP mailing list list > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >=20 > Hi Dino, >=20 > Could you be a bit more explicit? >=20 > Please assume the following operator requirements: >=20 > - In order to ensure the customer experience, an operator wants to = attract all traffic from the global Internet to LISP sites that it = supports through PITRs that it operates. > - In order to maintain financial viability, that same operator does = not want to attract any traffic from the global Internet to LISP sites = that it does not support through PITRs that it operates. >=20 > Do you agree that these are both valid requirements? If so, how can = the operator do this while advertising only large aggregates of the EID = address block to the global Internet? >=20 > = Ron >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, December 04, 2013 12:18 PM >> To: Ronald Bonica >> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list >> list >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>=20 >>> Assume that an operator deploys a PITR. What policy can that = operator >> enforce to ensure that it is compensated for all (or even most) of = the >> traffic that it carries across that PITR? >>=20 >> Through the same monetizing means it does today to attract any type = of >> traffic it wants to transit. >>=20 >> Dino >>=20 >>=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From sander@steffann.nl Wed Dec 4 23:02:13 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20041A1F5E for ; Wed, 4 Dec 2013 23:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToxdgGYVCza2 for ; Wed, 4 Dec 2013 23:02:12 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 814BA1A1F5D for ; Wed, 4 Dec 2013 23:02:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4D62158; Thu, 5 Dec 2013 08:02:07 +0100 (CET) X-Virus-Scanned: Debian 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 CgB9-RK-X7iZ; Thu, 5 Dec 2013 08:02:05 +0100 (CET) Received: from [37.77.56.82] (temp82.10ww.steffann.nl [37.77.56.82]) by mail.sintact.nl (Postfix) with ESMTPSA id B7B4356; Thu, 5 Dec 2013 08:02:04 +0100 (CET) References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> X-Mailer: iPhone Mail (11B554a) From: Sander Steffann Date: Thu, 5 Dec 2013 08:02:03 +0100 To: Dino Farinacci Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 07:02:14 -0000 Hi, > As I said before, the /32 advertisements of an EID-block are advertised wi= thin an ISP towards the edges of the network. Those edges are towards its cu= stomers so its customers, as sources in non-LISP sites, can reach destinatio= ns in LISP sites. So if it is only done this way, that means for global reachability of the LI= SP prefix at least one global transit provider has to run PITRs. They wouldn= 't mind attracting the traffic from their customers. That is what they are p= aid for :-) That would make it work, *if* we can convince the big transit(s= ). Cheers, Sander From jmh@joelhalpern.com Thu Dec 5 01:29:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036A01ACC8A for ; Thu, 5 Dec 2013 01:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylq3l_EYYut5 for ; Thu, 5 Dec 2013 01:29:01 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E00631AC7F0 for ; Thu, 5 Dec 2013 01:29:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B620F1C03708; Thu, 5 Dec 2013 01:28:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [62.49.66.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id AA2E91C03707; Thu, 5 Dec 2013 01:28:56 -0800 (PST) Message-ID: <52A04755.1010106@joelhalpern.com> Date: Thu, 05 Dec 2013 04:28:53 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ronald Bonica References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 09:29:04 -0000 There are two pieces here. We do hypothesize (and design for) having competing EID allocators and the ability for someone who got an allocation to move to a different EID allocator covering the same space. That is necessary to keep the prices for allocation and map maintenance competitive. PITRs can be run by anyone who wants to (with suitable authentication / authorization). So they can be run (as Dino hypothesizes) by the ISPs. They can be run by the EID allocators. Or by third parties. In all cases, they either have to be prepared for too much traffic or restrict what they advertise into the BGP system. Which is why I hope that it will make business sense for the allocators to run PITRs, since they are the only ones in the right place to easily provide aggregation of EID allocations. Yours, Joel PS: Some of this is discussed in the lisp-deployment draft. Some of it isn't. On 12/4/13 3:03 PM, Ronald Bonica wrote: > Hi Joel, > > In that model, assume that I obtain EID space from an EID allocator. At some point in the future, the PITR service that that EID allocator provides becomes inadequate. What is my can I do? > > Are there competing EID allocators? If I go with a competing EID allocator, do I have to renumber? > > Ron > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, December 04, 2013 12:02 PM >> To: Ronald Bonica; Dino Farinacci >> Cc: LISP mailing list list >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >> >> A partial answer that has been suggested is that the oeprator who >> deploys the PITR is an EID allocator rather than a conventional / >> existing ISP. Unfortunately, if LISp succeeds it is not clear that the >> compensation levels can match the increasing demand for traffic in the >> critical periods. >> >> Yours, >> Joel >> >> On 12/4/13 11:51 AM, Ronald Bonica wrote: >>> Dino, >>> >>> I am not understanding your response. Let me ask the question another >> way. >>> >>> Assume that an operator deploys a PITR. What policy can that operator >> enforce to ensure that it is compensated for all (or even most) of the >> traffic that it carries across that PITR? >>> >>> >>> Ron >>> >>> >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Wednesday, December 04, 2013 11:44 AM >>>> To: Ronald Bonica >>>> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list >>>> list >>>> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>>> >>>>> Luigi, >>>>> >>>>> Is this really what is going to happen? >>>>> >>>>> If a PITR announces the entire /32 into the global Internet, it >> puts >>>> itself on the forwarding path for the entire /32, and incurs the >> cost >>>> associated with transporting traffic towards every site in that /32. >>>> This is supportable only if the PITR operator is somehow compensated >>>> for carrying all of that traffic. >>>> >>>> But maybe only from a few sources. But if the /32 needs to be >> divided >>>> based on region, then maybe /40s could be advertised. But to the >>>> point about "few sources", the more PITRs there are, the better the >>>> load is shared. >>>> >>>> And I envision PITRs will be deployed on on-path boxes anyways. >> Those >>>> boxes right now can route to the entire Internet, they are called PE >>>> boxes, are they not Ron? >>>> >>>>> Isn't it more likely that the PITR operator will advertise only >>>> slices of the /32, with each of those slices being assigned to >> either >>>> its customers (from whom it collects revenue) or the customers of >>>> other operators with whom it has made financial arrangements? >>>> >>>> No it won't be that way. EIDs are provider independent. If you do >>>> what we suggest, we make no forward progress. >>>> >>>> Dino >>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> >> > > > From jmh@joelhalpern.com Thu Dec 5 02:03:56 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5A81ADE88 for ; Thu, 5 Dec 2013 02:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHkQHIiLqDtU for ; Thu, 5 Dec 2013 02:03:54 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id CE5441ADDD2 for ; Thu, 5 Dec 2013 02:03:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D81501C0389A; Thu, 5 Dec 2013 02:03:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [62.49.66.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 25ACB1C03898; Thu, 5 Dec 2013 02:03:49 -0800 (PST) Message-ID: <52A04F80.8020900@joelhalpern.com> Date: Thu, 05 Dec 2013 05:03:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Sander Steffann , Dino Farinacci References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> In-Reply-To: <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 10:03:56 -0000 Fortunately, the nature of the LISP architecture is that there is not one right way to deploy PITRs. There are several deployment models, each of which address different sets of customers. As a demonstration, if LISP PITR deployment required ISP support we would not have a running LISP testbed. Yours, Joel On 12/5/13 2:02 AM, Sander Steffann wrote: > Hi, > >> As I said before, the /32 advertisements of an EID-block are advertised within an ISP towards the edges of the network. Those edges are towards its customers so its customers, as sources in non-LISP sites, can reach destinations in LISP sites. > > So if it is only done this way, that means for global reachability of the LISP prefix at least one global transit provider has to run PITRs. They wouldn't mind attracting the traffic from their customers. That is what they are paid for :-) That would make it work, *if* we can convince the big transit(s). > > Cheers, > Sander > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From acabello@ac.upc.edu Thu Dec 5 02:56:40 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EBC1ADF26 for ; Thu, 5 Dec 2013 02:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsuu29hznQLc for ; Thu, 5 Dec 2013 02:56:37 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 828721ADBD0 for ; Thu, 5 Dec 2013 02:56:36 -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 rB5AuAxl008873; Thu, 5 Dec 2013 11:56:10 +0100 Received: from [192.168.0.200] (unknown [46.27.20.114]) by gw.ac.upc.edu (Postfix) with ESMTP id 735216B020C; Thu, 5 Dec 2013 11:54:04 +0100 (CET) Message-ID: <52A05BC6.9080008@ac.upc.edu> Date: Thu, 05 Dec 2013 11:56:06 +0100 From: Albert Cabellos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Damien Saucez References: <529F9088.8060504@ac.upc.edu> <91805CE8-01CC-4F6D-945F-D98D23A3F179@gmail.com> In-Reply-To: <91805CE8-01CC-4F6D-945F-D98D23A3F179@gmail.com> Content-Type: multipart/alternative; boundary="------------090404090704020104080703" Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 10:56:41 -0000 This is a multi-part message in MIME format. --------------090404090704020104080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, On 04/12/2013 22:40, Damien Saucez wrote: [snip] >> * Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests, >> hence there is a limit on the amplification attack. >> > > I think the analysis is complementary to the recommendation. In > RFC6830, no reason is given about why rate limit, here it shows why > this is recommended. > I agree, but the text seems to suggest that the amplification attack scales linearly and it is bounded to the maximum bandwidth (in control messages per second) of the attacker, this is not true. The attack is bounded by the rate-limit set at the xTR. >> >> * Section 4.3.2.3->Iīm having a hard time understanding this attack, >> even under attack, the ETR will reply with the "real nonce", at least >> once. Probably Iīm missing something. >> >> > > sure but if an attacker floods with random nonce, then when the node > will answer with the real nonce, it will already have been changed to > another one sent by the attacker. > Right, thanks. What about recommending that each nonce should be used at least once? So that a nonce canīt be overwritten if it has not been used. >> * Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent >> through the mapping system (not directly to the source RLOC), in this >> case the attack is still effective and involves the Mapping System, the >> Map-Server and the xTR (if operating in non-proxy mode). >> > > I am not sure I understand your question here. > Iīm referring to this paragraph: " The Map-Request message may also contain the SMR bit. Upon reception of a Map-Request message with the SMR bit, an ETR must return to the source of the Map-Request message a Map-Request message to retrieve the corresponding mapping. This raises similar problems as the RLOC record P bit discussed above except that as the Map-Request messages are smaller than Map-Reply messages, the risk of amplification attacks is reduced. " In some cases the SMR-invoked Map-Request is sent through the Mapping System (RFC6830): " If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request." So my point is that the attack is similar (true) but in some cases the amplification attack is through the Mapping System. Again the attack is bounded by the rate-limit set the xTR. In my view this should be also stated. Regards Albert > >> Editorial, please consider them suggestions, at the end it is a matter >> of taste of the writer/reader. > > ok, will take them into account according to other reviews. > >> > 1. Introduction >> > >> > The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. >> >> specified instead of defined? >> >> > The present document assesses the security level and identifies >> > security threats in the LISP specification if LISP is deployed >> in the >> > Internet (i.e., a public non-trustable environment). As a result of >> > the performed analysis, the document discusses the severity of the >> > threats and proposes recommendations to reach the same level of >> > security in LISP than in Internet today (e.g., without LISP). >> >> "(i.e., without LISP)" (not e.g.,) I understand that the authors are not >> referring to an example. >> >> > This document does not consider all the possible uses of LISP as >> > discussed in [RFC6830]. The document focuses on LISP unicast, >> > including as well LISP Interworking [RFC6832], LISP-MS >> [RFC6833], and >> > LISP Map-Versioning [RFC6834]. The reading of these documents is a >> > prerequisite for understanding the present document. >> >> Several deployment scenarios are discussed in >> draft-ietf-lisp-deployment, please consider citing it and discussing if >> the use-cases described in the deployment draft are covered by this >> analysis. >> >> > SA is an off-path attacker that is able to send spoofed packets, >> > i.e., packets with a different source IP address than its >> > assigned IP address. SA stands for Spoofing Attacker. >> >> SA attackers need access to the RLOC space, it might make sense to state >> this here. >> >> > 4.3.1.2. Threats concerning Interworking >> > >> > [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow >> >> Edit "and" instead of "And" >> >> On 02/12/2013 3:02, Terry Manderson wrote: >>> I would just like to highlight that the end of this LC draws near. >>> >>> Without review, this document cannot move forward. >>> >>> Cheers >>> Terry >>> >>> On 20/11/13 9:23 AM, "Terry Manderson" wrote: >>> >>>> All, >>>> >>>> As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have >>>> requested a work group last call. >>>> >>>> Here starts a 14 day last call for this document, the last call will end >>>> on >>>> Wednesday 4th December 2013. >>>> >>>> You will find its text here: >>>> http://tools.ietf.org/html/draft-ietf-lisp-threats-08 >>>> >>>> Please review this WG item and provide any last comments. >>>> >>>> Cheers >>>> Terry >>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > --------------090404090704020104080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

On 04/12/2013 22:40, Damien Saucez wrote:

[snip]
* Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.


I think the analysis is complementary to the recommendation.  In
RFC6830, no reason is given about why rate limit, here it shows why
this is recommended.

I agree, but the text seems to suggest that the amplification attack scales linearly and it is bounded to the maximum bandwidth (in control messages per second) of the attacker, this is not true. The attack is bounded by the rate-limit set at the xTR.


* Section 4.3.2.3->I´m having a hard time understanding this attack,
even under attack, the ETR will reply with the "real nonce", at least
once. Probably I´m missing something.



sure but if an attacker floods with random nonce, then when the node
will answer with the real nonce, it will already have been changed to
another one sent by the attacker.


Right, thanks. What about recommending that each nonce should be used at least once? So that a nonce can´t be overwritten if it has not been used.

* Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent
through the mapping system (not directly to the source RLOC), in this
case the attack is still effective and involves the Mapping System, the
Map-Server and the xTR (if operating in non-proxy mode).


I am not sure I understand your question here.


I´m referring to this paragraph:

"  The Map-Request message may also contain the SMR bit.  Upon reception
   of a Map-Request message with the SMR bit, an ETR must return to the
   source of the Map-Request message a Map-Request message to retrieve
   the corresponding mapping.  This raises similar problems as the RLOC
   record P bit discussed above except that as the Map-Request messages
   are smaller than Map-Reply messages, the risk of amplification
   attacks is reduced. "
In some cases the SMR-invoked Map-Request is sent through the Mapping System (RFC6830):

"      If the source Locator is the only
       Locator in the cached Locator-Set, the remote ITR SHOULD send a
       Map-Request to the database mapping system just in case the
       single Locator has changed and may no longer be reachable to
       accept the Map-Request."
So my point is that the attack is similar (true) but in some cases the amplification attack is through the Mapping System. Again the attack is bounded by the rate-limit set the xTR. In my view this should be also stated.

Regards

Albert

Editorial, please consider them suggestions, at the end it is a matter
of taste of the writer/reader.

ok, will take them into account according to other reviews.

> 1.  Introduction
>
>    The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].

specified instead of defined?

>    The present document assesses the security level and identifies
>    security threats in the LISP specification if LISP is deployed in the
>    Internet (i.e., a public non-trustable environment).  As a result of
>    the performed analysis, the document discusses the severity of the
>    threats and proposes recommendations to reach the same level of
>    security in LISP than in Internet today (e.g., without LISP).

"(i.e., without LISP)" (not e.g.,) I understand that the authors are not
referring to an example.

>    This document does not consider all the possible uses of LISP as
>    discussed in [RFC6830].  The document focuses on LISP unicast,
>    including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and
>    LISP Map-Versioning [RFC6834].  The reading of these documents is a
>    prerequisite for understanding the present document.

Several deployment scenarios are discussed in
draft-ietf-lisp-deployment, please consider citing it and discussing if
the use-cases described in the deployment draft are covered by this
analysis.

>    SA  is an off-path attacker that is able to send spoofed packets,
>        i.e., packets with a different source IP address than its
>        assigned IP address.  SA stands for Spoofing Attacker.

SA attackers need access to the RLOC space, it might make sense to state
this here.

> 4.3.1.2.  Threats concerning Interworking
>
>    [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow

Edit "and" instead of "And"

On 02/12/2013 3:02, Terry Manderson wrote:
I would just like to highlight that the end of this LC draws near.

Without review, this document cannot move forward.

Cheers
Terry

On 20/11/13 9:23 AM, "Terry Manderson" <terry.manderson@icann.org> wrote:


All,

As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have
requested a work group last call.

Here starts a 14 day last call for this document, the last call will end
on
Wednesday 4th December 2013.

You will find its text here:
http://tools.ietf.org/html/draft-ietf-lisp-threats-08

Please review this WG item and provide any last comments.

Cheers
Terry



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

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


--------------090404090704020104080703-- From ggx@gigix.net Thu Dec 5 07:39:19 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0581AE09C for ; Thu, 5 Dec 2013 07:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le3BJUueDpD8 for ; Thu, 5 Dec 2013 07:39:18 -0800 (PST) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9AF1AE08E for ; Thu, 5 Dec 2013 07:39:17 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so10923801wes.25 for ; Thu, 05 Dec 2013 07:39:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HJOiEa5DdjGFn3Nr46ZB/LW1mMzOhi8dWqcXu1XA4ws=; b=Uew1N75MHZoEM0xwt5/Og5+F+oE9+XNRDjHIeHOK14FbDHsdHuRzokCCKuhuZcggGS gf6V3YCjJDlt4X9+8fWtYP1Rga2uOH57P4Zx63B92HfqhZRUMCTUIgUaPC9gvLs18b2M o8NeAA28Uav7qRr+PPe2ivMO4b+0m4PqUSDGnT0yU+h6Th4FzTtdVDg6D1d34O7PH8gH H87BBD5W14+JnUcKOPEUj7Lz6ryaubf3/VATuR7SZL/WIsqIMIwLaxWc2enT+Lejhz6m 2at+1BSHvXKVVfp6eeDHe9UIsArh9Nsii+ybHLr7/TKWaWW/rWQLp31Ixp15rE0DCjrt TJpg== X-Gm-Message-State: ALoCoQnG8y5hrWr0RFAkxuSD30a4nmOcWu23TzoAHup30e5BAS56QHPyR+ubCrth166f76FDHRCE X-Received: by 10.180.221.38 with SMTP id qb6mr12430299wic.8.1386257954238; Thu, 05 Dec 2013 07:39:14 -0800 (PST) Received: from dhcp164-06.enst.fr (dhcp164-05.enst.fr. [137.194.165.5]) by mx.google.com with ESMTPSA id pi6sm7356936wic.3.2013.12.05.07.39.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 07:39:13 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luigi Iannone In-Reply-To: <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> Date: Thu, 5 Dec 2013 16:39:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 15:39:19 -0000 On 4 Dec. 2013, at 16:26 , Ronald Bonica wrote: >>=20 >> PITR should announce the largest aggregate possible, ideally the /32. Hi Ron, note as well that I used the word =93ideally=94=85 because IMHO it will = not happen in reality ;-) The sentence came along with the idea to avoid deploy personal PITRs. If every LISP site gets an EID prefix and announces it in BGP by himself = we would end up polluting the BGP table with EID prefixes.=20 This is something we absolutely do not want. To avoid misinterpretation I would change the following sentence = currently in the document (section 4) To guarantee reachability from the Legacy Internet the prefix = may be announced in the BGP routing infrastructure by one or more = PITR(s) as part of larger aggregates (ideally just the entire LISP EID = block). in just To guarantee reachability from the Legacy Internet EID prefixes = may be announced in the BGP routing infrastructure by one or more = PITR(s) as part of larger aggregates. and conclude the section with the paragraph (proposed in previous = discussion with Geoff): The EID block must be used for LISP experimentation and must not = be=20 used as normal prefix. Interworking between the EID block = sub-prefixes=20 and the non-LISP Internet is done according to [RFC6832]=20 and [I-D.ietf-lisp-deployment]. Do you folks think this is OK? Luigi >>=20 >=20 > Luigi, >=20 > Is this really what is going to happen?=20 >=20 > If a PITR announces the entire /32 into the global Internet, it puts = itself on the forwarding path for the entire /32, and incurs the cost = associated with transporting traffic towards every site in that /32. = This is supportable only if the PITR operator is somehow compensated for = carrying all of that traffic. >=20 > Isn't it more likely that the PITR operator will advertise only slices = of the /32, with each of those slices being assigned to either its = customers (from whom it collects revenue) or the customers of other = operators with whom it has made financial arrangements? >=20 > Ron >=20 >=20 From farinacci@gmail.com Thu Dec 5 07:41:49 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE31AE07B for ; Thu, 5 Dec 2013 07:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y9BQNBufI2V for ; Thu, 5 Dec 2013 07:41:47 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id B09C51AE074 for ; Thu, 5 Dec 2013 07:41:47 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so26103584pbc.35 for ; Thu, 05 Dec 2013 07:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=03ZTv9/gsNDY4XGLFi2dFrDS7VUfSh/w8T36HzE36ms=; b=ITxfgd0oGV2pz0W+MkEVxTJnW/n/mbyvf/DnakRoGpMTZtYKD36BoV9dLmubWq7ua3 hVG1ALXjFuRS4zWXfi3JleG0EafO1cWBr9Zq2/B9R9UfKop09YTPucEbhFJFNf+kwwuI butqo3lHuHEHqevcisFWol40/9KWoNONb8rFOSrVgVUHU1RO8Uo4SRQeIAX4qBSCkThK cv2yacjV0C1IYj3fb1hrj4DYTsHKPsBawDRXu7QMNhM0PZ3rMVUZ9gNkrjUbpwJcDrvJ POLXcLPQhUPJ1t1EnCfhpnolJwG/Hjo35uoEu9H5yEDm7I8Wg/frwQz6Uyad5BMRWWXB izxw== X-Received: by 10.66.253.169 with SMTP id ab9mr9475475pad.156.1386258104407; Thu, 05 Dec 2013 07:41:44 -0800 (PST) Received: from [192.168.1.166] ([207.145.253.66]) by mx.google.com with ESMTPSA id wp8sm145476768pbc.26.2013.12.05.07.41.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 07:41:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <52A04755.1010106@joelhalpern.com> Date: Thu, 5 Dec 2013 07:41:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <68008FDD-57EE-4A99-864A-38FB67B648B1@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> <52A04755.1010106@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 15:41:49 -0000 > PITRs can be run by anyone who wants to (with suitable authentication = / authorization). So they can be run (as Dino hypothesizes) by the = ISPs. They can be run by the EID allocators. Or by third parties. In = all cases, they either have to be prepared for too much traffic or = restrict what they advertise into the BGP system. Which is why I hope = that it will make business sense for the allocators to run PITRs, since = they are the only ones in the right place to easily provide aggregation = of EID allocations. I envision existing ISPs to run PxTRs because they have capacity planned = for data movement. Where MSPs are adminstrative and policy driven. They = don't need the bandwidth capacity as the data-plane providers. So, in = theory they could do both but I envision that an existing data-plane ISP = would offer MSP services versus the other way around. Dino From farinacci@gmail.com Thu Dec 5 07:44:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6C71AE074 for ; Thu, 5 Dec 2013 07:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQDr_kXhxWBK for ; Thu, 5 Dec 2013 07:44:22 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED801AE064 for ; Thu, 5 Dec 2013 07:44:22 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so24897273pdj.12 for ; Thu, 05 Dec 2013 07:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6na85YbN0IgKFNBQNld5C5WCpVhofyL/YgF5fyrovaY=; b=WuD5bKse14sXnaMmIiaV9gWnTZVboIrnVO8aRkSqybUgADFTLGXNRNDMWVQIyIa/Ih W+wkT9iGDcDzDqza/BWrywwHS6iagGF0TTq5unVn64sx1LMfA0tN1UOSi+JhQoTRWrxv T5BoystIvYck9I6iyuJPqzm50boFvCOum2ddM/HBZhTwxeqbYp1PuQElaDJwMDn96XzL zp8mg/LNX+VjaPZKa7Z4qMfoIZD5zYsxV4I2hycXb+/+bM3dJhzFGZYZOs33vu/BWE5l GBHyEdkE5fMWRbtSVlj19L2bmBl/1kji+AmjtYMrh+pEOzO1+UZou6y67C+dlyE9T2o4 lm0Q== X-Received: by 10.67.3.68 with SMTP id bu4mr25618055pad.144.1386258258846; Thu, 05 Dec 2013 07:44:18 -0800 (PST) Received: from [192.168.1.166] ([207.145.253.66]) by mx.google.com with ESMTPSA id yg3sm168232417pab.16.2013.12.05.07.44.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 07:44:17 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> Date: Thu, 5 Dec 2013 07:44:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0A9D9121-965B-4473-8901-9F720A55C622@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 15:44:23 -0000 > To avoid misinterpretation I would change the following sentence = currently in the document (section 4) >=20 > To guarantee reachability from the Legacy Internet the prefix = may be > announced in the BGP routing infrastructure by one or more = PITR(s) as > part of larger aggregates (ideally just the entire LISP EID = block). >=20 > in just >=20 > To guarantee reachability from the Legacy Internet EID prefixes = may be > announced in the BGP routing infrastructure by one or more = PITR(s) as > part of larger aggregates. Could you use "restrictively announced"? Or "announced with heavy policy = applied"? Dino >=20 >=20 > and conclude the section with the paragraph (proposed in previous = discussion with Geoff): >=20 > The EID block must be used for LISP experimentation and must not = be=20 > used as normal prefix. Interworking between the EID block = sub-prefixes=20 > and the non-LISP Internet is done according to [RFC6832]=20 > and [I-D.ietf-lisp-deployment]. >=20 >=20 > Do you folks think this is OK? From rbonica@juniper.net Thu Dec 5 08:06:15 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6011AE0A3 for ; Thu, 5 Dec 2013 08:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOG6RMJ1qz_j for ; Thu, 5 Dec 2013 08:06:13 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 207B31AE09E for ; Thu, 5 Dec 2013 08:06:12 -0800 (PST) Received: from mail217-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Dec 2013 16:06:08 +0000 Received: from mail217-va3 (localhost [127.0.0.1]) by mail217-va3-R.bigfish.com (Postfix) with ESMTP id 4D0B4180296; Thu, 5 Dec 2013 16:06:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail217-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51444003)(51704005)(199002)(189002)(13464003)(377454003)(65816001)(54316002)(2656002)(74706001)(77982001)(80022001)(81542001)(74366001)(87936001)(66066001)(85306002)(79102001)(63696002)(59766001)(81342001)(87266001)(56776001)(4396001)(83072001)(31966008)(76786001)(47976001)(47736001)(81686001)(33646001)(19580395003)(77096001)(80976001)(47446002)(54356001)(46102001)(76482001)(76796001)(49866001)(74876001)(74662001)(53806001)(74316001)(69226001)(50986001)(76576001)(74502001)(51856001)(19580405001)(83322001)(81816001)(56816005)(90146001)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail217-va3 (localhost.localdomain [127.0.0.1]) by mail217-va3 (MessageSwitch) id 1386259567184927_2228; Thu, 5 Dec 2013 16:06:07 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.229]) by mail217-va3.bigfish.com (Postfix) with ESMTP id 1E3B2780061; Thu, 5 Dec 2013 16:06:07 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Dec 2013 16:06:06 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Thu, 5 Dec 2013 16:06:06 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.825.14; Thu, 5 Dec 2013 16:06:03 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Thu, 5 Dec 2013 16:06:03 +0000 From: Ronald Bonica To: Sander Steffann , Dino Farinacci Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0wAAEI/IAAAjLDYAAVFwsAAAV/aoAAEvA/cA== Date: Thu, 5 Dec 2013 16:06:02 +0000 Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> In-Reply-To: <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 00514A2FE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 16:06:15 -0000 Sander, I think that what you are saying is true. Do folks agree? Ron > -----Original Message----- > From: Sander Steffann [mailto:sander@steffann.nl] > Sent: Thursday, December 05, 2013 2:02 AM > To: Dino Farinacci > Cc: Ronald Bonica; Luigi Iannone; Geoff Huston; LISP mailing list list > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >=20 > Hi, >=20 > > As I said before, the /32 advertisements of an EID-block are > advertised within an ISP towards the edges of the network. Those edges > are towards its customers so its customers, as sources in non-LISP > sites, can reach destinations in LISP sites. >=20 > So if it is only done this way, that means for global reachability of > the LISP prefix at least one global transit provider has to run PITRs. > They wouldn't mind attracting the traffic from their customers. That is > what they are paid for :-) That would make it work, *if* we can > convince the big transit(s). >=20 > Cheers, > Sander >=20 >=20 From sander@steffann.nl Thu Dec 5 08:31:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8D1AE0B3 for ; Thu, 5 Dec 2013 08:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs1_EwkT0Tg3 for ; Thu, 5 Dec 2013 08:31:46 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2801AE0AA for ; Thu, 5 Dec 2013 08:31:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id EE37340; Thu, 5 Dec 2013 17:31:41 +0100 (CET) X-Virus-Scanned: Debian 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 kk2RFySRZL0n; Thu, 5 Dec 2013 17:31:40 +0100 (CET) Received: from [IPv6:2a00:8640:1::90fa:2ea9:c372:b795] (unknown [IPv6:2a00:8640:1:0:90fa:2ea9:c372:b795]) by mail.sintact.nl (Postfix) with ESMTPSA id D0B8A34; Thu, 5 Dec 2013 17:31:39 +0100 (CET) References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> Mime-Version: 1.0 (1.0) In-Reply-To: <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <9DC5D2BF-C81A-4A6A-97F7-44E490CD2F66@steffann.nl> X-Mailer: iPhone Mail (11B554a) From: Sander Steffann Date: Thu, 5 Dec 2013 17:31:40 +0100 To: Luigi Iannone Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 16:31:47 -0000 Hi Luigi, > Do you folks think this is OK? Ok for me, Sander From darlewis@cisco.com Thu Dec 5 09:16:13 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556A61AE0C9 for ; Thu, 5 Dec 2013 09:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OABl8zYmAmU6 for ; Thu, 5 Dec 2013 09:16:08 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 032E01AE0C7 for ; Thu, 5 Dec 2013 09:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1663; q=dns/txt; s=iport; t=1386263765; x=1387473365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=i+Ci0mLHaDvCzlvHSVGbp7hw4KDC0Om4dFzw9O/vaIg=; b=k6RESz0PA2+wiwd1re1OQv57yLAURxzs/p1BOoSNNlCuFqz1wL5nBNk2 NPKLIcKLKEZQzd0ubSNKypwzWZzUM8S7+lB/YUPXIbUh4mtVnaTdtbR3z 2p9X5qw21BfEPsoTDtBh5wTne3/2BnRPgGs71NZGd4VBXQYt7X15jMIZH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAES0oFKtJV2c/2dsb2JhbABZgwc4U7htgRwWdIIlAQEBAwEBAQE3MgILBQcEAgEIDgMEAQEfCQcnCxQJCAIEDgWHfAYNwVgTBI5NMwcGgxqBEwOYFJITgymCKg X-IronPort-AV: E=Sophos;i="4.93,834,1378857600"; d="scan'208";a="4597398" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 05 Dec 2013 17:16:04 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB5HG4rV013375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 17:16:04 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 11:16:04 -0600 From: "Darrel Lewis (darlewis)" To: Ronald Bonica Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: AQHO8d2t5+cYlvPnY0CXsMJoDYWKCg== Date: Thu, 5 Dec 2013 17:16:04 +0000 Message-ID: <82227356-2D80-4FD9-B565-FB71DED19970@cisco.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.60] Content-Type: text/plain; charset="us-ascii" Content-ID: <437CDA891ACA6147A0F9878282C54457@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 17:16:13 -0000 Its certainly one, but as Joel said, not the only, way one could envision g= lobal deployment of PxTRs. Another one is that regional LISP mapping provi= ders announce their customer's (PI) EID prefixes. In the latter case, the = gains to the global routing systems are modest, but at least individual sit= es are not deaggregating for TE purposes. -Darrel On Dec 5, 2013, at 8:06 AM, Ronald Bonica wrote: > Sander, >=20 > I think that what you are saying is true. Do folks agree? >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: Sander Steffann [mailto:sander@steffann.nl] >> Sent: Thursday, December 05, 2013 2:02 AM >> To: Dino Farinacci >> Cc: Ronald Bonica; Luigi Iannone; Geoff Huston; LISP mailing list list >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>=20 >> Hi, >>=20 >>> As I said before, the /32 advertisements of an EID-block are >> advertised within an ISP towards the edges of the network. Those edges >> are towards its customers so its customers, as sources in non-LISP >> sites, can reach destinations in LISP sites. >>=20 >> So if it is only done this way, that means for global reachability of >> the LISP prefix at least one global transit provider has to run PITRs. >> They wouldn't mind attracting the traffic from their customers. That is >> what they are paid for :-) That would make it work, *if* we can >> convince the big transit(s). >>=20 >> Cheers, >> Sander >>=20 >>=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Thu Dec 5 10:45:18 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4529E1AE107 for ; Thu, 5 Dec 2013 10:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDtxkwv4e_aP for ; Thu, 5 Dec 2013 10:45:16 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 45AED1AE11B for ; Thu, 5 Dec 2013 10:45:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2E9A51C62546; Thu, 5 Dec 2013 10:45:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [81.145.171.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6BF3D1C62545; Thu, 5 Dec 2013 10:45:12 -0800 (PST) Message-ID: <52A0C9B6.50701@joelhalpern.com> Date: Thu, 05 Dec 2013 13:45:10 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Dino Farinacci References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> <52A04755.1010106@joelhalpern.com> <68008FDD-57EE-4A99-864A-38FB67B648B1@gmail.com> In-Reply-To: <68008FDD-57EE-4A99-864A-38FB67B648B1@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 18:45:18 -0000 And ISPs are certainly allowed to run PITRs. They can either advertise only the customers they support, or forward traffic for other folks who may well not even be their customers. Their call. But the LISP RFCs are not going to mandate that. And I expect that there will be other alternatives. Yours, Joel On 12/5/13 10:41 AM, Dino Farinacci wrote: >> PITRs can be run by anyone who wants to (with suitable authentication / authorization). So they can be run (as Dino hypothesizes) by the ISPs. They can be run by the EID allocators. Or by third parties. In all cases, they either have to be prepared for too much traffic or restrict what they advertise into the BGP system. Which is why I hope that it will make business sense for the allocators to run PITRs, since they are the only ones in the right place to easily provide aggregation of EID allocations. > > I envision existing ISPs to run PxTRs because they have capacity planned for data movement. Where MSPs are adminstrative and policy driven. They don't need the bandwidth capacity as the data-plane providers. So, in theory they could do both but I envision that an existing data-plane ISP would offer MSP services versus the other way around. > > Dino > > > From gih@apnic.net Thu Dec 5 11:51:35 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969A01AE026 for ; Thu, 5 Dec 2013 11:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.798 X-Spam-Level: X-Spam-Status: No, score=-100.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMyjNGsWfD91 for ; Thu, 5 Dec 2013 11:51:33 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [203.119.98.120]) by ietfa.amsl.com (Postfix) with SMTP id 6DE781AE018 for ; Thu, 5 Dec 2013 11:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=USMQwNxxuu9FeyKf1ttrbBlIi2vq3nq1zphyHj+z9p8=; b=3lALeXR7mrrUX14y5KvZG5Ih3t7GT//t9mCLm1YUq3yzdOJppcjhAHT60D97YU7fRrubkQDC89TF9 Gr36DaEd9MG0mHRV2tsbRmcLjaEBVUTFkOxgfeyxKBz7uOBMosWcJXFIxJizjCoikvcOgvW2qvfwPY 9cBcZPG0e3LKE3cc= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 6 Dec 2013 05:45:02 +1000 (EST) Received: from [203.119.42.9] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 6 Dec 2013 05:45:11 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Geoff Huston In-Reply-To: <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> Date: Fri, 6 Dec 2013 06:45:12 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 19:51:35 -0000 On 6 Dec 2013, at 2:39 am, Luigi Iannone wrote: >=20 > To avoid misinterpretation I would change the following sentence = currently in the document (section 4) >=20 > To guarantee reachability from the Legacy Internet the prefix = may be > announced in the BGP routing infrastructure by one or more = PITR(s) as > part of larger aggregates (ideally just the entire LISP EID = block). >=20 > in just >=20 > To guarantee reachability from the Legacy Internet EID prefixes = may be s/guarantee/provide/ there are no guarantees in this world! s/Legacy Internet/non-LISP Internet/ The prospects of LISP prevailing in time are by no means assured and the = use of the term "Legacy" in this context is neither informative or even = remotely accurate at present. Remove it. > announced in the BGP routing infrastructure by one or more = PITR(s) as > part of larger aggregates. s/part of large aggregates/more specifics/ please use terminology that is consistent with standard routing terms. = In this case the text is referring to "more specifics" so please use = that term. The text would also add the sentence: "The intended scope of these more = specific prefix advertisements may be deliberated limited by the PITR to = reflect local routing policies." >=20 >=20 > and conclude the section with the paragraph (proposed in previous = discussion with Geoff): >=20 > The EID block must be used for LISP experimentation and must not = be=20 > used as normal prefix. Interworking between the EID block = sub-prefixes=20 > and the non-LISP Internet is done according to [RFC6832]=20 > and [I-D.ietf-lisp-deployment]. s/used as a normal prefix/advertised in the form of more specific route = advertisements in the non-LISP inter-domain routing environment/ >=20 >=20 > Do you folks think this is OK? >=20 Not yet. Please review these suggested specific changes. Geoff From rbonica@juniper.net Thu Dec 5 11:59:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2BF1AE04F for ; Thu, 5 Dec 2013 11:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGoZGxnA8vE6 for ; Thu, 5 Dec 2013 11:59:51 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 716801AE0C5 for ; Thu, 5 Dec 2013 11:59:51 -0800 (PST) Received: from mail168-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Dec 2013 19:59:47 +0000 Received: from mail168-va3 (localhost [127.0.0.1]) by mail168-va3-R.bigfish.com (Postfix) with ESMTP id 63B144049B; Thu, 5 Dec 2013 19:59:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail168-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(4396001)(47736001)(2656002)(87266001)(54316002)(85306002)(74366001)(15975445006)(85852002)(81342001)(77982001)(56776001)(59766001)(69226001)(19580395003)(50986001)(47976001)(80976001)(74662001)(49866001)(76796001)(33646001)(77096001)(74502001)(79102001)(83072001)(83322001)(87936001)(66066001)(81816001)(80022001)(76482001)(74316001)(54356001)(74876001)(15202345003)(46102001)(81542001)(31966008)(63696002)(81686001)(76576001)(51856001)(47446002)(76786001)(53806001)(65816001)(74706001)(90146001)(56816005)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3 (MessageSwitch) id 138627358577543_15595; Thu, 5 Dec 2013 19:59:45 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.236]) by mail168-va3.bigfish.com (Postfix) with ESMTP id 07ED8460241; Thu, 5 Dec 2013 19:59:45 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Dec 2013 19:59:43 +0000 Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.383.1; Thu, 5 Dec 2013 19:59:42 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.825.14; Thu, 5 Dec 2013 19:59:40 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Thu, 5 Dec 2013 19:59:39 +0000 From: Ronald Bonica To: Dino Farinacci , "Joel M. Halpern" Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0wAAB5fAAABjOuYAAcRdWAAA0FPgAABuJdsA== Date: Thu, 5 Dec 2013 19:59:38 +0000 Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> <52A04755.1010106@joelhalpern.com> <68008FDD-57EE-4A99-864A-38FB67B648B1@gmail.com> In-Reply-To: <68008FDD-57EE-4A99-864A-38FB67B648B1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 00514A2FE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 19:59:54 -0000 Folks, >From the conversation so far, I glean that there are two competing PITR dep= loyment models. These are: - User pays - Altruistic party pays Recent experience tells us that only the "user pays" model is viable. So, w= e are left to choose between the following variations of the "user pays" mo= del: 1) Owner of a LISP site pays 2) Owner of a non-LISP site that access LISP sites pays In http://www.ietf.org/mail-archive/web/lisp/current/msg04955.html, Joel de= scribes a scenario that realizes model #1. In this scenario, a portion of t= he LISP address block is assigned to an EID allocator. For the purpose of e= xample, assume that a /40 is assigned to the EID Allocator. From this /40, = the EID allocator assigns smaller address blocks to its customers. The EID = operator also operates one or more PITRs and advertises the /40, as a singl= e aggregate prefix, from each PITR. The owner of the LISP site pays the EID= allocator for these services. In http://www.ietf.org/mail-archive/web/lisp/current/msg04965.html, Paul de= scribes a scenario that realizes model #2. In this scenario, an ISP deploys= one or more PITRs and announces the entire LISP address block (/32) from e= ach of them. The ISP announces the /32 to its customers only and with the n= o-export community set. The ISP distributes the cost of the PITRs among its= customers in some equitable manner. The major advantage of model #1 is that it allows LISP sites to be globally= accessible, even when some ISPs do not deploy PITRs. However, the major di= sadvantage of model #1 is that it leads to de-aggregation of the LISP addre= ss block. De-aggregation may be significant if customers are not required t= o renumber when the move from one EID allocator to another. The major advantage of model #2 is that it allows the LISP address block to= be advertised as a single, aggregate prefix. However, in this model, LISP = sites are not accessible from autonomous systems that do not deploy PITRs. Does everybody agree with this much? Ron From gih@apnic.net Thu Dec 5 12:04:17 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB01ACCDF for ; Thu, 5 Dec 2013 12:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy8n14LTaaeR for ; Thu, 5 Dec 2013 12:04:16 -0800 (PST) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 9A5811AE0EA for ; Thu, 5 Dec 2013 12:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:content-type:mime-version:subject:from:in-reply-to: date:cc:content-transfer-encoding:message-id:references:to:x-mailer: return-path; bh=DhgY7wNfbf67sQhj3CHqCBasAxZai3beuFGFE431DbQ=; b=QVnlu/DEFEMoqmbmIBkMrnCrykWuEFe1BoOXEpYiC1yn/sPBSqlOvGUu9mrV/JYv5R7Bz9Qt/Gfhb oWlfHfvp4jvkE7MLS5T3OGaFqJVw2fYqT9natsRfEGBKY0zvd8R7jrSLOewO8lYAhUO4WuiMb5DNPh ZPcivlDi78SIUabk= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 6 Dec 2013 06:04:09 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802:90fc:97c2:1a5f:d67d) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 6 Dec 2013 06:04:09 +1000 Received: from [203.119.42.9] (203.119.101.249) by IAMDA2.org.apnic.net (203.119.111.21) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 6 Dec 2013 06:04:08 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Geoff Huston In-Reply-To: Date: Fri, 6 Dec 2013 07:04:08 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> To: Ronald Bonica X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 20:04:18 -0000 > Sander, >=20 > I think that what you are saying is true. Do folks agree? >=20 agree, yes. But at the same time I should point out that this approach has some serious downside risk. This limited advertisement scope was the theory behind the intended = routing scope of 2002::/16. The theory was that every provider would advertise 2002::/16 to its customers, and noone would need to take the unfunded = transit traffic hit of advertising this gateway prefix globally. And some providers did precisely that. However most folk did absolutely = nothing, so reachability into the 2002::/16 space was erratic, unmanaged and = non-functional. The approach described below by Sander could be seen as a replay of this same piecemeal limited scope advertisement scenario, and has the same = risk. What's the risk? Again 2002::/16 has some clues. While the experiment is of small scale and the traffic levels are = insignificant some folk will advertise the /32 prefix globally and absorb the unfunded transit traffic as part of the experiment. This sounds great, but it has some serious downsides. The consequent routing from the non-LISP world to the LISP world may = well have highly inefficient and lengthy paths for many, as the "closest" = gateway may well be on the other side of the planet. (e.g. from Australia I = still send most of my Teredo traffic via Amsterdam - obviously performance = sucks when this happens!) The consequent impact on performance of these extended "dog leg" paths = that need to head to the PITR gateway to transit between the LISP and non-LISP = routing domains which may well have some negative impact on the perceptions of LISP = performance in the context of this experiment. i.e. it appears that the negative = 6to4 perceptions were not only due to widespread use of local protocol 41 filters, but also = due to the asymmetric and highly erratic transit paths between end users and the = sparsely deployed 6to4 gateways. Geoff On 6 Dec 2013, at 3:06 am, Ronald Bonica wrote: >=20 >=20 >> -----Original Message----- >> From: Sander Steffann [mailto:sander@steffann.nl] >> Sent: Thursday, December 05, 2013 2:02 AM >> To: Dino Farinacci >> Cc: Ronald Bonica; Luigi Iannone; Geoff Huston; LISP mailing list = list >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>=20 >> Hi, >>=20 >>> As I said before, the /32 advertisements of an EID-block are >> advertised within an ISP towards the edges of the network. Those = edges >> are towards its customers so its customers, as sources in non-LISP >> sites, can reach destinations in LISP sites. >>=20 >> So if it is only done this way, that means for global reachability of >> the LISP prefix at least one global transit provider has to run = PITRs. >> They wouldn't mind attracting the traffic from their customers. That = is >> what they are paid for :-) That would make it work, *if* we can >> convince the big transit(s). >>=20 >> Cheers, >> Sander >>=20 >>=20 >=20 >=20 From farinacci@gmail.com Thu Dec 5 13:08:40 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057961AE110 for ; Thu, 5 Dec 2013 13:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu-DQnRKhoSI for ; Thu, 5 Dec 2013 13:08:38 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43B1AE106 for ; Thu, 5 Dec 2013 13:08:38 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id uo5so26505622pbc.25 for ; Thu, 05 Dec 2013 13:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P8tjKBL+md4Vw4zG15PpXKePskzojxePPbEv1qQfHOY=; b=UXOQlqkoaotnVgL2GuUoho8zE2hFBlU7dJ0mvIsBvEPPJ5zvHmfV0a+e9ZiFjYeI0o rdRKVHej8RGfyDhNkJ/wBXl6FWl1wLrQPLdiv2cLRVi4ToKni96zGocGZCEkh301bFTv XrjwWMciJEktM8UrWE2jIw+YwTR1f74ThmoZgxrAWiLL0nMdarfmBo2PAxsa5K7vgSaq VhOH5iTIxyfTwxY9U3C+0vgaBSKanW9H/lAHWeHMm6K23rgeBhWEbVcwUsMJqz86O2dQ RR5ZsnLfKr2Eo8VP/siAFsbLt4gbwnhSMQ7F+GXq//BnSaPWgml84F8cU3ZKxgoR4mUw fe+g== X-Received: by 10.68.12.138 with SMTP id y10mr55192831pbb.101.1386277713512; Thu, 05 Dec 2013 13:08:33 -0800 (PST) Received: from [192.168.5.162] (ip-64-134-239-215.public.wayport.net. [64.134.239.215]) by mx.google.com with ESMTPSA id ha10sm146819209pbd.17.2013.12.05.13.07.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 13:08:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: Date: Thu, 5 Dec 2013 13:07:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <95A874F8-1B82-46E7-A328-AD0F50C6CAB8@gmail.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> To: Geoff Huston X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 21:08:40 -0000 > The consequent routing from the non-LISP world to the LISP world may = well > have highly inefficient and lengthy paths for many, as the "closest" = gateway > may well be on the other side of the planet. (e.g. from Australia I = still > send most of my Teredo traffic via Amsterdam - obviously performance = sucks when this > happens!) This is possibly why the overlay could go very far to the edges. To the = point of in the hosts or the attached networking device. We have seen = this happen, a bit, with the data center overlays. Dino P.S. Let the host versus network battle begin ... again ... From damien.saucez@gmail.com Thu Dec 5 15:05:36 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B6F1AE1CD for ; Thu, 5 Dec 2013 15:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znm4bCeYRboT for ; Thu, 5 Dec 2013 15:05:34 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6351AE17E for ; Thu, 5 Dec 2013 15:05:34 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id t60so1573062wes.34 for ; Thu, 05 Dec 2013 15:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jdDSScfRHqK2wkfKfGcjZHkTbqPgOCej3ZA6BZxJJWA=; b=Ho4O545QK4Z40JXjevkQdDfuizWVTTYPVbM+rW2xpKmKGW8WAQAocOV8VCByvAQsRv hxTbpHbSOqKrlNNG5+G8XBctQHKGu06I74HQDR85CnIHoVG7gnHhYUAXkY+bkJqGy6nV Y12mYyOlxotSRJZXDaJQOyCwRmZfxUMTgs4lGqFrnaTl0OIEfJRuHnxgu5P5OoZ8Bg4V WmBYWRXEnLX27W1tCsun2ov53jE/o9ZZ7VC8WEDBIZWpnobVKaFFsagY8KLR4Q9ILk2B a7KvkrYQ1NtqMhJU1pbnxXBrp4bps/7c4IzKqU9KfEb/wDb5KfW3bzlCqdg61eFCf7CV 7HGA== X-Received: by 10.180.13.142 with SMTP id h14mr146847wic.3.1386284730505; Thu, 05 Dec 2013 15:05:30 -0800 (PST) Received: from [192.168.1.73] (LVelizy-156-46-22-251.w80-11.abo.wanadoo.fr. [80.11.231.251]) by mx.google.com with ESMTPSA id je17sm594527wic.4.2013.12.05.15.05.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 15:05:29 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_96A63A67-368D-4A0B-A0FC-03639D03F07A" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Damien Saucez In-Reply-To: <52A05BC6.9080008@ac.upc.edu> Date: Fri, 6 Dec 2013 00:05:25 +0100 Message-Id: References: <529F9088.8060504@ac.upc.edu> <91805CE8-01CC-4F6D-945F-D98D23A3F179@gmail.com> <52A05BC6.9080008@ac.upc.edu> To: Albert Cabellos X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 05 Dec 2013 23:05:36 -0000 --Apple-Mail=_96A63A67-368D-4A0B-A0FC-03639D03F07A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 05 Dec 2013, at 11:56, Albert Cabellos wrote: > Hi, >=20 > On 04/12/2013 22:40, Damien Saucez wrote: >=20 > [snip] >>> * Section 4.3.2.2->RFC6830 already recommends rate-limiting = Map-Requests, >>> hence there is a limit on the amplification attack. >>>=20 >>=20 >> I think the analysis is complementary to the recommendation. In >> RFC6830, no reason is given about why rate limit, here it shows why >> this is recommended. >>=20 > I agree, but the text seems to suggest that the amplification attack = scales linearly and it is bounded to the maximum bandwidth (in control = messages per second) of the attacker, this is not true. The attack is = bounded by the rate-limit set at the xTR. >=20 >>>=20 >>> * Section 4.3.2.3->I=B4m having a hard time understanding this = attack, >>> even under attack, the ETR will reply with the "real nonce", at = least >>> once. Probably I=B4m missing something. >>>=20 >>>=20 >>=20 >> sure but if an attacker floods with random nonce, then when the node >> will answer with the real nonce, it will already have been changed to >> another one sent by the attacker. >>=20 >=20 > Right, thanks. What about recommending that each nonce should be used = at least once? So that a nonce can=B4t be overwritten if it has not been = used. >=20 Isn't that the definition of a nonce? I don't see how it helps. Imagine - Legit sends Nonce1=20 - Bad guy sends Nonce2 with spoof address of Legit - Nonce1 arrives, but it is too late, it has been overridden by Nonce2 already so the return with Nonce1is just ignored. >>> * Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent >>> through the mapping system (not directly to the source RLOC), in = this >>> case the attack is still effective and involves the Mapping System, = the >>> Map-Server and the xTR (if operating in non-proxy mode). >>>=20 >>=20 >> I am not sure I understand your question here. >>=20 >=20 > I=B4m referring to this paragraph: >=20 > " The Map-Request message may also contain the SMR bit. Upon = reception > of a Map-Request message with the SMR bit, an ETR must return to = the > source of the Map-Request message a Map-Request message to retrieve > the corresponding mapping. This raises similar problems as the = RLOC > record P bit discussed above except that as the Map-Request = messages > are smaller than Map-Reply messages, the risk of amplification > attacks is reduced. " >=20 > In some cases the SMR-invoked Map-Request is sent through the Mapping = System (RFC6830): >=20 > " If the source Locator is the only > Locator in the cached Locator-Set, the remote ITR SHOULD send a > Map-Request to the database mapping system just in case the > single Locator has changed and may no longer be reachable to > accept the Map-Request." > So my point is that the attack is similar (true) but in some cases the = amplification attack is through the Mapping System. Again the attack is = bounded by the rate-limit set the xTR. In my view this should be also = stated. ok, we could say so Damien Saucez >=20 > Regards >=20 > Albert >>=20 >>> Editorial, please consider them suggestions, at the end it is a = matter >>> of taste of the writer/reader. >>=20 >> ok, will take them into account according to other reviews. >>=20 >>> > 1. Introduction >>> > >>> > The Locator/ID Separation Protocol (LISP) is defined in = [RFC6830]. >>>=20 >>> specified instead of defined? >>>=20 >>> > The present document assesses the security level and identifies >>> > security threats in the LISP specification if LISP is deployed = in the >>> > Internet (i.e., a public non-trustable environment). As a = result of >>> > the performed analysis, the document discusses the severity of = the >>> > threats and proposes recommendations to reach the same level of >>> > security in LISP than in Internet today (e.g., without LISP). >>>=20 >>> "(i.e., without LISP)" (not e.g.,) I understand that the authors are = not >>> referring to an example. >>>=20 >>> > This document does not consider all the possible uses of LISP = as >>> > discussed in [RFC6830]. The document focuses on LISP unicast, >>> > including as well LISP Interworking [RFC6832], LISP-MS = [RFC6833], and >>> > LISP Map-Versioning [RFC6834]. The reading of these documents = is a >>> > prerequisite for understanding the present document. >>>=20 >>> Several deployment scenarios are discussed in >>> draft-ietf-lisp-deployment, please consider citing it and discussing = if >>> the use-cases described in the deployment draft are covered by this >>> analysis. >>>=20 >>> > SA is an off-path attacker that is able to send spoofed = packets, >>> > i.e., packets with a different source IP address than its >>> > assigned IP address. SA stands for Spoofing Attacker. >>>=20 >>> SA attackers need access to the RLOC space, it might make sense to = state >>> this here. >>>=20 >>> > 4.3.1.2. Threats concerning Interworking >>> > >>> > [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to = allow >>>=20 >>> Edit "and" instead of "And" >>>=20 >>> On 02/12/2013 3:02, Terry Manderson wrote: >>>> I would just like to highlight that the end of this LC draws near. >>>>=20 >>>> Without review, this document cannot move forward. >>>>=20 >>>> Cheers >>>> Terry >>>>=20 >>>> On 20/11/13 9:23 AM, "Terry Manderson" = wrote: >>>>=20 >>>>> All, >>>>>=20 >>>>> As requested in Vancouver, the authors of = draft-ietf-lisp-threats-08 have >>>>> requested a work group last call. >>>>>=20 >>>>> Here starts a 14 day last call for this document, the last call = will end >>>>> on >>>>> Wednesday 4th December 2013. >>>>>=20 >>>>> You will find its text here: >>>>> http://tools.ietf.org/html/draft-ietf-lisp-threats-08 >>>>>=20 >>>>> Please review this WG item and provide any last comments. >>>>>=20 >>>>> Cheers >>>>> Terry >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 --Apple-Mail=_96A63A67-368D-4A0B-A0FC-03639D03F07A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 05 Dec 2013, at 11:56, Albert = Cabellos <acabello@ac.upc.edu> = wrote:

=20 =20
Hi,

On 04/12/2013 22:40, Damien Saucez wrote:

[snip]
=
* Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.


I think the analysis is complementary to the recommendation.  In
RFC6830, no reason is given about why rate limit, here it shows why
this is recommended.

I agree, but the text seems to suggest that the amplification attack scales linearly and it is bounded to the maximum bandwidth (in control messages per second) of the attacker, this is not true. The attack is bounded by the rate-limit set at the xTR.

=

* Section 4.3.2.3->I=B4m having a hard time = understanding this attack,
even under attack, the ETR will reply with the "real nonce", at least
once. Probably I=B4m missing something.



sure but if an attacker floods with random nonce, then when the node
will answer with the real nonce, it will already have been changed to
another one sent by the attacker.


Right, thanks. What about recommending that each nonce should be used at least once? So that a nonce can=B4t be overwritten if it has not been used.


Isn't that the definition = of a nonce? I don't see how it = helps.

Imagine

- Legit = sends Nonce1 
- Bad guy sends Nonce2 with spoof address = of Legit
- Nonce1 arrives, but it is too late, it has = been overridden by Nonce2
already so the return with Nonce1is = just ignored.

=
* Section = 4.4.1-> In some cases the SMR-invoked Map-Request is sent
through the mapping system (not directly to the source RLOC), in this
case the attack is still effective and involves the Mapping System, the
Map-Server and the xTR (if operating in non-proxy = mode).


I am not sure I understand your question here.


I=B4m referring to this paragraph:

"  The Map-Request message may also contain the SMR bit.  Upon reception
   of a Map-Request message with the SMR bit, an ETR must return to the
   source of the Map-Request message a Map-Request message to retrieve
   the corresponding mapping.  This raises similar problems as the RLOC
   record P bit discussed above except that as the Map-Request messages
   are smaller than Map-Reply messages, the risk of amplification
   attacks is reduced. "
In some cases the SMR-invoked Map-Request is sent through the Mapping System (RFC6830):

"      If the source Locator is the =
only
       Locator in the cached Locator-Set, the remote ITR SHOULD send a
       Map-Request to the database mapping system just in case the
       single Locator has changed and may no longer be reachable to
       accept the Map-Request."
So my point is that the attack is similar (true) but in some cases the amplification attack is through the Mapping System. Again the attack is bounded by the rate-limit set the xTR. In my view this should be also stated.

ok, we = could say so

Damien = Saucez


Regards

Albert
=

Editorial, please consider them suggestions, at the end it is a matter
of taste of the writer/reader.

ok, will take them into account according to other reviews.

> 1.  = Introduction
>
>    The Locator/ID Separation Protocol = (LISP) is defined in [RFC6830].

specified instead of defined?

>    The present document assesses the = security level and identifies
>    security threats in the LISP = specification if LISP is deployed in the
>    Internet (i.e., a public = non-trustable environment).  As a result of
>    the performed analysis, the = document discusses the severity of the
>    threats and proposes = recommendations to reach the same level of
>    security in LISP than in Internet = today (e.g., without LISP).

"(i.e., without LISP)" (not e.g.,) I understand that the authors are not
referring to an example.

>    This document does not consider all = the possible uses of LISP as
>    discussed in [RFC6830].  The = document focuses on LISP unicast,
>    including as well LISP Interworking = [RFC6832], LISP-MS [RFC6833], and
>    LISP Map-Versioning = [RFC6834].  The reading of these documents is a
>    prerequisite for understanding the = present document.

Several deployment scenarios are discussed in
draft-ietf-lisp-deployment, please consider citing it and discussing if
the use-cases described in the deployment draft are covered by this
analysis.

>    SA  is an off-path attacker = that is able to send spoofed packets,
>        i.e., = packets with a different source IP address than its
>        assigned IP = address.  SA stands for Spoofing Attacker.

SA attackers need access to the RLOC space, it might make sense to state
this here.

> 4.3.1.2.  Threats concerning Interworking
>
>    [RFC6832] defines Proxy-ITR And = Proxy-ETR network elements to allow

Edit "and" instead of "And"

On 02/12/2013 3:02, Terry Manderson wrote:
I would just like to highlight that the =
end of this LC draws near.

Without review, this document cannot move forward.

Cheers
Terry

On 20/11/13 9:23 AM, "Terry Manderson" <terry.manderson@icann.org>=
; wrote:


All,

As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 =
have
requested a work group last call.

Here starts a 14 day last call for this document, the last call will end
on
Wednesday 4th December 2013.

You will find its text here:
http://tool=
s.ietf.org/html/draft-ietf-lisp-threats-08

Please review this WG item and provide any last comments.

Cheers
Terry



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

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



= --Apple-Mail=_96A63A67-368D-4A0B-A0FC-03639D03F07A-- From sander@steffann.nl Fri Dec 6 01:09:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEC61AD8DB for ; Fri, 6 Dec 2013 01:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05rpMn715k03 for ; Fri, 6 Dec 2013 01:09:52 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 301C21AD7C1 for ; Fri, 6 Dec 2013 01:09:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B015F58; Fri, 6 Dec 2013 10:09:46 +0100 (CET) X-Virus-Scanned: Debian 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 UEcH5LjnEzFB; Fri, 6 Dec 2013 10:09:44 +0100 (CET) Received: from [37.77.56.82] (temp82.10ww.steffann.nl [37.77.56.82]) by mail.sintact.nl (Postfix) with ESMTPSA id A5C5346; Fri, 6 Dec 2013 10:09:43 +0100 (CET) References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <46CB916D-F1E3-48E5-8CE3-93F9F0F5B7AB@steffann.nl> X-Mailer: iPhone Mail (11B554a) From: Sander Steffann Date: Fri, 6 Dec 2013 10:09:43 +0100 To: Geoff Huston Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 06 Dec 2013 09:09:54 -0000 Hi Geoff, I was more thinking of one or more large (glibal) transit providers to inclu= de LISP PITR services as an official managed service with anycast nodes arou= nd the world. I definitely don't want to repeat the 6to4 disaster where ther= e are a few sparsely distributed volunteer nodes, and to make it usable we c= annot expect each and every ISP to run a PITR for their own customers. Certa= inly not while it is experimental. Transit providers actually get paid for the traffic they handle, so for them= it can be economically interesting to offer well performing PITR services. Met vriendelijke groet, Sander Steffann Op 5 dec. 2013 om 21:04 heeft Geoff Huston het volgende gesc= hreven: >> Sander, >>=20 >> I think that what you are saying is true. Do folks agree? >=20 > agree, yes. But at the same time I should point out that this approach > has some serious downside risk. >=20 > This limited advertisement scope was the theory behind the intended routin= g > scope of 2002::/16. The theory was that every provider would advertise > 2002::/16 to its customers, and noone would need to take the unfunded tran= sit > traffic hit of advertising this gateway prefix globally. >=20 > And some providers did precisely that. However most folk did absolutely no= thing, > so reachability into the 2002::/16 space was erratic, unmanaged and non-fu= nctional. > The approach described below by Sander could be seen as a replay of this > same piecemeal limited scope advertisement scenario, and has the same risk= . >=20 > What's the risk? >=20 > Again 2002::/16 has some clues. >=20 > While the experiment is of small scale and the traffic levels are insignif= icant > some folk will advertise the /32 prefix globally and absorb the unfunded > transit traffic as part of the experiment. This sounds great, but it has > some serious downsides. >=20 > The consequent routing from the non-LISP world to the LISP world may well > have highly inefficient and lengthy paths for many, as the "closest" gatew= ay > may well be on the other side of the planet. (e.g. from Australia I still= > send most of my Teredo traffic via Amsterdam - obviously performance sucks= when this > happens!) >=20 > The consequent impact on performance of these extended "dog leg" paths tha= t need > to head to the PITR gateway to transit between the LISP and non-LISP routi= ng domains > which may well have some negative impact on the perceptions of LISP perfor= mance > in the context of this experiment. i.e. it appears that the negative 6to4 p= erceptions were > not only due to widespread use of local protocol 41 filters, but also due t= o the > asymmetric and highly erratic transit paths between end users and the spar= sely deployed > 6to4 gateways. >=20 > Geoff >=20 >=20 >=20 >=20 >> On 6 Dec 2013, at 3:06 am, Ronald Bonica wrote: >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Sander Steffann [mailto:sander@steffann.nl] >>> Sent: Thursday, December 05, 2013 2:02 AM >>> To: Dino Farinacci >>> Cc: Ronald Bonica; Luigi Iannone; Geoff Huston; LISP mailing list list >>> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>>=20 >>> Hi, >>>=20 >>>> As I said before, the /32 advertisements of an EID-block are >>> advertised within an ISP towards the edges of the network. Those edges >>> are towards its customers so its customers, as sources in non-LISP >>> sites, can reach destinations in LISP sites. >>>=20 >>> So if it is only done this way, that means for global reachability of >>> the LISP prefix at least one global transit provider has to run PITRs. >>> They wouldn't mind attracting the traffic from their customers. That is >>> what they are paid for :-) That would make it work, *if* we can >>> convince the big transit(s). >>>=20 >>> Cheers, >>> Sander >=20 From ggx@gigix.net Fri Dec 6 07:07:26 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54F51ADFCA for ; Fri, 6 Dec 2013 07:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT1IbYBHJuwc for ; Fri, 6 Dec 2013 07:07:23 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id E9D901ADFF3 for ; Fri, 6 Dec 2013 07:07:22 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so769600wes.38 for ; Fri, 06 Dec 2013 07:07:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Me0n+Ahb9tg9uIaunDBBqI1H2gqnP98gS+aPnyYowR4=; b=lYZrWttNbT4dOU/oaOnxDM5iHsHS0+Ni3GFOrw0TL1/zu9thWHgEUCnrM8CYcYRWfe ETASAHXhpGIxyIs3pzCzNL9NeU7L1JGLsa3e5gF3X7O6AMIHVAGEYZ9BlxOqHK5ofanG HoF6d8/DDZ5go0mNvohwlgLFSKuzVmPvEgkEKsDSdIGtqSvF4kRrlF0tBGoKuLwQqbo+ 4zUliSVUpcrNcRFxb0AqmFn4hlXBaVwTIhDaEPdvWndxTsvx1vG4r8vebL4P8eMdpUGk k/w3+FDVbJ0SU/Nw+pOBJ+81YrRHlPkb6x+w86AAmp6Lhho76Mt9M03h0FJgCs6AvIIq ZNyQ== X-Gm-Message-State: ALoCoQlzh0W/vqgQhnrbFFtj+90UCrQ7cT89/JB78qwyqtwLkbgkxJ0XyEvaxTxYOQ5RH97VRvnM X-Received: by 10.194.250.100 with SMTP id zb4mr3698655wjc.62.1386342438670; Fri, 06 Dec 2013 07:07:18 -0800 (PST) Received: from dhcp164-06.enst.fr (dhcp164-05.enst.fr. [137.194.165.5]) by mx.google.com with ESMTPSA id s20sm7051480wib.1.2013.12.06.07.07.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 07:07:17 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luigi Iannone In-Reply-To: Date: Fri, 6 Dec 2013 16:07:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0AE887A6-CCA9-4555-935B-FEFA29FD1FD8@gigix.net> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> To: Geoff Huston X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 06 Dec 2013 15:07:27 -0000 Hi Geoff, thanks for the suggestions. If I include as well the previous comment from Dino the text right now = looks like this: To provide reachability from the non-LISP Internet EID prefix = may be restrictively announced in the BGP routing infrastructure by one = or more=20 PITR(s) as more specifics. The intended scope of these more = specific=20 prefix advertisements may be deliberated limited by the PITR to = reflect=20 local routing policies. The EID block must be used for LISP experimentation and must not = be=20 advertised in the form of more specific route advertisements in = the=20 non-LISP inter-domain routing environment. Interworking between = the=20 EID block sub-prefixes and the non-LISP Internet is done = according to=20 [RFC6832] and [I-D.ietf-lisp-deployment]. Does it look better now? Luigi On 5 Dec. 2013, at 20:45 , Geoff Huston wrote: >=20 > On 6 Dec 2013, at 2:39 am, Luigi Iannone wrote: >>=20 >> To avoid misinterpretation I would change the following sentence = currently in the document (section 4) >>=20 >> To guarantee reachability from the Legacy Internet the prefix = may be >> announced in the BGP routing infrastructure by one or more = PITR(s) as >> part of larger aggregates (ideally just the entire LISP EID = block). >>=20 >> in just >>=20 >> To guarantee reachability from the Legacy Internet EID prefixes = may be >=20 > s/guarantee/provide/ >=20 > there are no guarantees in this world! >=20 > s/Legacy Internet/non-LISP Internet/ >=20 > The prospects of LISP prevailing in time are by no means assured and = the use of the term "Legacy" in this context is neither informative or = even remotely accurate at present. Remove it. >=20 >=20 >> announced in the BGP routing infrastructure by one or more = PITR(s) as >> part of larger aggregates. >=20 >=20 > s/part of large aggregates/more specifics/ >=20 > please use terminology that is consistent with standard routing terms. = In this case the text is referring to "more specifics" so please use = that term. >=20 >=20 > The text would also add the sentence: "The intended scope of these = more specific prefix advertisements may be deliberated limited by the = PITR to reflect local routing policies." >=20 >=20 >=20 >=20 >>=20 >>=20 >> and conclude the section with the paragraph (proposed in previous = discussion with Geoff): >>=20 >> The EID block must be used for LISP experimentation and must not = be=20 >> used as normal prefix. Interworking between the EID block = sub-prefixes=20 >> and the non-LISP Internet is done according to [RFC6832]=20 >> and [I-D.ietf-lisp-deployment]. >=20 >=20 >=20 > s/used as a normal prefix/advertised in the form of more specific = route advertisements in the non-LISP inter-domain routing environment/ >=20 >=20 >=20 >>=20 >>=20 >> Do you folks think this is OK? >>=20 >=20 >=20 > Not yet. Please review these suggested specific changes. >=20 > Geoff >=20 >=20 >=20 >=20 From rbonica@juniper.net Fri Dec 6 08:41:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA71AE33D for ; Fri, 6 Dec 2013 08:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDuUVGrD_yDe for ; Fri, 6 Dec 2013 08:41:44 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 577DF1AE09E for ; Fri, 6 Dec 2013 08:41:44 -0800 (PST) Received: from mail2-db9-R.bigfish.com (10.174.16.230) by DB9EHSOBE013.bigfish.com (10.174.14.76) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Dec 2013 16:41:40 +0000 Received: from mail2-db9 (localhost [127.0.0.1]) by mail2-db9-R.bigfish.com (Postfix) with ESMTP id 2CC7B1C064A; Fri, 6 Dec 2013 16:41:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail2-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(479174003)(51704005)(377454003)(24454002)(13464003)(77096001)(56776001)(87936001)(50986001)(54316002)(49866001)(74876001)(66066001)(80022001)(76796001)(74366001)(2656002)(85852002)(81686001)(81542001)(47736001)(76786001)(47976001)(53806001)(74662001)(4396001)(81816001)(46102001)(74502001)(87266001)(31966008)(69226001)(83322001)(76576001)(80976001)(19580405001)(54356001)(63696002)(79102001)(74316001)(19580395003)(81342001)(65816001)(77982001)(47446002)(76482001)(85306002)(51856001)(74706001)(83072001)(56816005)(59766001)(33646001)(90146001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail2-db9 (localhost.localdomain [127.0.0.1]) by mail2-db9 (MessageSwitch) id 1386348098606167_23961; Fri, 6 Dec 2013 16:41:38 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.247]) by mail2-db9.bigfish.com (Postfix) with ESMTP id 904BF500057; Fri, 6 Dec 2013 16:41:38 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Dec 2013 16:41:37 +0000 Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Fri, 6 Dec 2013 16:41:36 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.825.14; Fri, 6 Dec 2013 16:41:34 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Fri, 6 Dec 2013 16:41:34 +0000 From: Ronald Bonica To: "Joel M. Halpern" , Dino Farinacci Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0wAAB5fAAABjOuYAAcRdWAAA0FPgAABmhRAAAt6maw Date: Fri, 6 Dec 2013 16:41:33 +0000 Message-ID: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> <52A04755.1010106@joelhalpern.com> <68008FDD-57EE-4A99-864A-38FB67B648B1@gmail.com> <52A0C9B6.50701@joelhalpern.com> In-Reply-To: <52A0C9B6.50701@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] x-forefront-prvs: 0052308DC6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 06 Dec 2013 16:41:47 -0000 Joel, Are there any rules regarding a) who can run a PITR and b) what prefixes th= at PITR can advertise? If so, who enforces the rules? How? Ron > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, December 05, 2013 1:45 PM > To: Dino Farinacci > Cc: Ronald Bonica; LISP mailing list list > Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >=20 > And ISPs are certainly allowed to run PITRs. > They can either advertise only the customers they support, or forward > traffic for other folks who may well not even be their customers. > Their call. > But the LISP RFCs are not going to mandate that. > And I expect that there will be other alternatives. >=20 > Yours, > Joel >=20 > On 12/5/13 10:41 AM, Dino Farinacci wrote: > >> PITRs can be run by anyone who wants to (with suitable > authentication / authorization). So they can be run (as Dino > hypothesizes) by the ISPs. They can be run by the EID allocators. Or > by third parties. In all cases, they either have to be prepared for > too much traffic or restrict what they advertise into the BGP system. > Which is why I hope that it will make business sense for the allocators > to run PITRs, since they are the only ones in the right place to easily > provide aggregation of EID allocations. > > > > I envision existing ISPs to run PxTRs because they have capacity > planned for data movement. Where MSPs are adminstrative and policy > driven. They don't need the bandwidth capacity as the data-plane > providers. So, in theory they could do both but I envision that an > existing data-plane ISP would offer MSP services versus the other way > around. > > > > Dino > > > > > > >=20 From rogerj@gmail.com Fri Dec 6 10:54:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D71AE0FA for ; Fri, 6 Dec 2013 10:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqVrFrODq5e0 for ; Fri, 6 Dec 2013 10:54:51 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A30201ADFF7 for ; Fri, 6 Dec 2013 10:54:50 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id a1so1191808wgh.3 for ; Fri, 06 Dec 2013 10:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xyukxRVUvFSSn2SPb21Ew5aEzysesXgXR58nHvk39/k=; b=PZDj5UiwdBoYwjFNOIMUM5TEXNKzepNc1eSG/7R+lOF6MqlJIdSq2941yQG2llJXy7 AxEc0SXtAXIjVt94xcbLJqOXK/YDOFsxO2ThreDQM4o8aklJofCzP4slV/yvB8V14eub KQuc7s4ZWZioEfZwtVC4LJ9I5NLGWoVINTwWVRXGQSZw6P4UCUR3K8CXsGhMLVhfWNj8 tLh2xnkr3S2WFG0JU/ddYq336jgPrHBlH4XBchIg2ISvt9lsl3HSiZAvfhXy7sVEhhGA epet/s4GJ4u1JP3M2XkwyJoUBQ/FORfoiWIO8OM399XvMbhsrL+nJwMNcUfAmfdqDxc+ cu7w== MIME-Version: 1.0 X-Received: by 10.180.76.171 with SMTP id l11mr3826941wiw.13.1386356086338; Fri, 06 Dec 2013 10:54:46 -0800 (PST) Received: by 10.217.89.4 with HTTP; Fri, 6 Dec 2013 10:54:46 -0800 (PST) In-Reply-To: References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> Date: Fri, 6 Dec 2013 19:54:46 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Ronald Bonica Content-Type: text/plain; charset=ISO-8859-1 Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 06 Dec 2013 18:54:53 -0000 On Thu, Dec 5, 2013 at 5:06 PM, Ronald Bonica wrote: > Sander, > > I think that what you are saying is true. Do folks agree? Yes, Sander's explanation was better than the one I was working on. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From rogerj@gmail.com Fri Dec 6 10:56:26 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8C71ADF22 for ; Fri, 6 Dec 2013 10:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a8iBJYSJyp6 for ; Fri, 6 Dec 2013 10:56:25 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id D64471AE074 for ; Fri, 6 Dec 2013 10:56:23 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y10so1195750wgg.0 for ; Fri, 06 Dec 2013 10:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eyIfXFUBDrdxV7uD6/M9xcRzBaQYFvnsjWANcbAbHA8=; b=Hsw4AXvsfuRt6FOdlcNACIaqqO+mP3ARA5hmrxIWrYn4YVnCK2DhTpFcA6CmnXoH4I XLcLk4ATIHuTh8YTTVWV7GBnHnu1AZoN2frvdvbdeYep8HL/1YD0Svfdfw1ji0Oa8FFu XkRR1DWpdIU1ncsxwdEqHAeaSIZHEEBwk4W3vwMSOxulpQx0mS1o7FjCKtXQ8cF3zgv7 CQBjYfC8cDd2P69iGyRmAozJhe6vKabhVG040WKUowtvGwl2pGX8Su2/txqghaF5L8Li Wel/sMafQQnqv3cnI8b9Th+hPwt4zW4pJNY88TLRlmNFVHKnA0Ovda3jUPpg9NFOKGBe fqlA== MIME-Version: 1.0 X-Received: by 10.194.237.226 with SMTP id vf2mr4564798wjc.58.1386356179646; Fri, 06 Dec 2013 10:56:19 -0800 (PST) Received: by 10.217.89.4 with HTTP; Fri, 6 Dec 2013 10:56:19 -0800 (PST) In-Reply-To: <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <1A2E86D7-25F9-42FC-9DD7-23AE9B628EBC@gigix.net> Date: Fri, 6 Dec 2013 19:56:19 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Luigi Iannone Content-Type: text/plain; charset=ISO-8859-1 Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 06 Dec 2013 18:56:26 -0000 On Thu, Dec 5, 2013 at 4:39 PM, Luigi Iannone wrote: > Do you folks think this is OK? Yes it's ok for me. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From rcallon@juniper.net Fri Dec 6 11:04:49 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E91AE066 for ; Fri, 6 Dec 2013 11:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV-DsawVA4by for ; Fri, 6 Dec 2013 11:04:47 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 515651AE087 for ; Fri, 6 Dec 2013 11:04:47 -0800 (PST) Received: from mail78-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Dec 2013 19:04:43 +0000 Received: from mail78-co1 (localhost [127.0.0.1]) by mail78-co1-R.bigfish.com (Postfix) with ESMTP id 5F61ED403C5; Fri, 6 Dec 2013 19:04:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail78-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(51444003)(24454002)(377454003)(51704005)(81816001)(83072001)(54356001)(63696002)(79102001)(19580405001)(87936001)(53806001)(69226001)(80022001)(15975445006)(87266001)(47446002)(47976001)(2656002)(65816001)(19580395003)(83322001)(81542001)(74502001)(85852002)(74662001)(80976001)(50986001)(77982001)(81686001)(49866001)(4396001)(74316001)(47736001)(66066001)(31966008)(46102001)(76576001)(76482001)(85306002)(51856001)(74876001)(74706001)(54316002)(76786001)(81342001)(56776001)(74366001)(76796001)(33646001)(59766001)(90146001)(56816005)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.18; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail78-co1 (localhost.localdomain [127.0.0.1]) by mail78-co1 (MessageSwitch) id 1386356680521699_5395; Fri, 6 Dec 2013 19:04:40 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.231]) by mail78-co1.bigfish.com (Postfix) with ESMTP id 7BA2E8C0047; Fri, 6 Dec 2013 19:04:40 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Dec 2013 19:04:40 +0000 Received: from CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Fri, 6 Dec 2013 19:04:33 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.820.5; Fri, 6 Dec 2013 19:04:30 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0820.005; Fri, 6 Dec 2013 19:04:30 +0000 From: Ross Callon To: Sander Steffann , Geoff Huston Thread-Topic: [lisp] WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVegCW6fiAABscEYAACyoxAAA2EA2AACSu+TAAAx8vAAAAIX0wAAEI/IAAAjLDYAAVFwsAAAV/aoAAEvA/cAAIYCAAABtvqYAAFGwAUA== Date: Fri, 6 Dec 2013 19:04:29 +0000 Message-ID: <8492967c05d74f468201b8d500403d49@CO2PR05MB636.namprd05.prod.outlook.com> References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <4C244965-DB17-4C93-AB61-28F24D34E099@gmail.com> <4e2de5d7cb4441669e8a7e624840ae86@CO1PR05MB442.namprd05.prod.outlook.com> <9EEBF040-BCA5-48DE-AFE0-CC69DDDB78BA@gmail.com> <90C17949-C70D-4953-B2A7-18D7DC23929E@steffann.nl> <46CB916D-F1E3-48E5-8CE3-93F9F0F5B7AB@steffann.nl> In-Reply-To: <46CB916D-F1E3-48E5-8CE3-93F9F0F5B7AB@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.18] x-forefront-prvs: 0052308DC6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 06 Dec 2013 19:04:49 -0000 > ... and to make it usable we cannot expect each and every ISP to run a PI= TR for their own customers Yes indeed. A problem with all service providers offering PITR service to=20 their own customers only is that for quite a while not all service provider= s will choose to do anything related to LISP. Thus in the intermediate term i= f=20 some service providers offer and use LISP, and others do not, there needs t= o=20 be some way for customers from the "no LISP" service providers to send traf= fic=20 to customers using LISP from the "I support LISP" service providers. Thus to me it seems that service providers who support LISP for their=20 customers are going to need to supply the PITRs to reach their customers.=20 Of course it is possible that you could be right and this could be one global provider who can offer service in many parts of the world (assuming that someone chooses to be that provider).=20 Ross -----Original Message----- From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Sander Steffann Sent: Friday, December 06, 2013 4:10 AM To: Geoff Huston Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 Hi Geoff, I was more thinking of one or more large (glibal) transit providers to incl= ude LISP PITR services as an official managed service with anycast nodes ar= ound the world. I definitely don't want to repeat the 6to4 disaster where t= here are a few sparsely distributed volunteer nodes, and to make it usable = we cannot expect each and every ISP to run a PITR for their own customers. = Certainly not while it is experimental. Transit providers actually get paid for the traffic they handle, so for the= m it can be economically interesting to offer well performing PITR services= . Met vriendelijke groet, Sander Steffann Op 5 dec. 2013 om 21:04 heeft Geoff Huston het volgende ges= chreven: >> Sander, >>=20 >> I think that what you are saying is true. Do folks agree? >=20 > agree, yes. But at the same time I should point out that this approach > has some serious downside risk. >=20 > This limited advertisement scope was the theory behind the intended routi= ng > scope of 2002::/16. The theory was that every provider would advertise > 2002::/16 to its customers, and noone would need to take the unfunded tra= nsit > traffic hit of advertising this gateway prefix globally. >=20 > And some providers did precisely that. However most folk did absolutely n= othing, > so reachability into the 2002::/16 space was erratic, unmanaged and non-f= unctional. > The approach described below by Sander could be seen as a replay of this > same piecemeal limited scope advertisement scenario, and has the same ris= k. >=20 > What's the risk? >=20 > Again 2002::/16 has some clues. >=20 > While the experiment is of small scale and the traffic levels are insigni= ficant > some folk will advertise the /32 prefix globally and absorb the unfunded > transit traffic as part of the experiment. This sounds great, but it has > some serious downsides. >=20 > The consequent routing from the non-LISP world to the LISP world may well > have highly inefficient and lengthy paths for many, as the "closest" gate= way > may well be on the other side of the planet. (e.g. from Australia I stil= l > send most of my Teredo traffic via Amsterdam - obviously performance suck= s when this > happens!) >=20 > The consequent impact on performance of these extended "dog leg" paths th= at need > to head to the PITR gateway to transit between the LISP and non-LISP rout= ing domains > which may well have some negative impact on the perceptions of LISP perfo= rmance > in the context of this experiment. i.e. it appears that the negative 6to4= perceptions were > not only due to widespread use of local protocol 41 filters, but also due= to the > asymmetric and highly erratic transit paths between end users and the spa= rsely deployed > 6to4 gateways. >=20 > Geoff >=20 >=20 >=20 >=20 >> On 6 Dec 2013, at 3:06 am, Ronald Bonica wrote: >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Sander Steffann [mailto:sander@steffann.nl] >>> Sent: Thursday, December 05, 2013 2:02 AM >>> To: Dino Farinacci >>> Cc: Ronald Bonica; Luigi Iannone; Geoff Huston; LISP mailing list list >>> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >>>=20 >>> Hi, >>>=20 >>>> As I said before, the /32 advertisements of an EID-block are >>> advertised within an ISP towards the edges of the network. Those edges >>> are towards its customers so its customers, as sources in non-LISP >>> sites, can reach destinations in LISP sites. >>>=20 >>> So if it is only done this way, that means for global reachability of >>> the LISP prefix at least one global transit provider has to run PITRs. >>> They wouldn't mind attracting the traffic from their customers. That is >>> what they are paid for :-) That would make it work, *if* we can >>> convince the big transit(s). >>>=20 >>> Cheers, >>> Sander >=20 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Sun Dec 8 18:20:44 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841941AE1AE for ; Sun, 8 Dec 2013 18:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU62OxcCYDTf for ; Sun, 8 Dec 2013 18:20:43 -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 1ECF51AE17D for ; Sun, 8 Dec 2013 18:20:43 -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; Sun, 8 Dec 2013 18:20:38 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Sun, 8 Dec 2013 18:20:35 -0800 Thread-Topic: draft-iannone-eid-block-mgmnt-03 Thread-Index: Ac70hT/DFEiBhf+rSTuZ1h++V03vOQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3469436435_49149219" MIME-Version: 1.0 Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 09 Dec 2013 02:20:44 -0000 --B_3469436435_49149219 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The call for adoption of this draft is closed. I saw no-one speaking against adoption, with that and the in-room consensus at Vancouver IETF to adopt this as a work item - eid-block-mgmnt is now a LISP WG item. Authors, can you please submit a WG version at your earliest convenience? Cheers Terry On 20/11/13 9:25 AM, "Terry Manderson" wrote: >In Vancouver the chairs received a request for the following document to >be >adopted as a WG item. > >http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 > >Here starts a 14 day call for adoption, this call will end on >Wednesday the 4th December, 2013. > >Please email the WG list stating that you either accept, or not accept, >the >item. > >If you email to support the acceptance of this document as a WG item, >please >also indicate if you are able and willing to either contribute to, or >review, (or both) the draft. > >Sitting in silence does not indicate support, please respond >appropriately. > >Cheers >Terry > --B_3469436435_49149219 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 AQkEMRYEFJmUlTV78RHY6v18pgB5mkm+1Bc1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTIwOTAyMjAzNVowDQYJKoZIhvcNAQEBBQAEggEAIbqOnN2f 7mI1DWEg1ZTHesltId5jP4FlUaKQ2OkdF+/GxisQnfytUJu15t6+XJbMjtfUzNhKwzsxsOcr NLBIUSuuNezxcYeZH4X6Qw45nZ7ak/oUbIHVMhoNYaJ5mlmGRzLq/IdwgU8h85eBlWOEAE3i xNDnMwIEVznJ+fDjXj6Ah0fPlrBNs8lQrnjNfcn6bd+zANMZOYfCkfd2age6N7M6Im2BfcqF oDSUVtWIFIpWs77bE1GkPWbm8sD7A+WrTS6RTPd/EeInz2TovIBjQaKOczD1AtogMeH/mrSi qZOonmmUDFZiWYqKZNk0qByQYD4y/Qi9JaCeO0OSJrDyqw== --B_3469436435_49149219-- From internet-drafts@ietf.org Mon Dec 9 01:39:58 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA60E1AE265; Mon, 9 Dec 2013 01:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IGtRk965ZBg; Mon, 9 Dec 2013 01:39:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9EB1AE264; Mon, 9 Dec 2013 01:39:56 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209093956.16095.81606.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 01:39:56 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-mgmnt-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: 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, 09 Dec 2013 09:39: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 EID Block Management Guidelines Author(s) : Luigi Iannone Roger Jorgensen David Conrad Filename : draft-ietf-lisp-eid-block-mgmnt-00.txt Pages : 11 Date : 2013-12-09 Abstract: This document proposes an allocation framework for the management of the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]). The framework described relies on hierarchical distribution of the address space with sub-prefixes allocated on a temporary basis to requesting organizations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From heinerhummel@aol.com Mon Dec 9 02:33:45 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3611AE26D for ; Mon, 9 Dec 2013 02:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9zlEcO7dTaf for ; Mon, 9 Dec 2013 02:33:43 -0800 (PST) Received: from omr-m04.mx.aol.com (omr-m04.mx.aol.com [64.12.143.78]) by ietfa.amsl.com (Postfix) with ESMTP id 13BF41AE26C for ; Mon, 9 Dec 2013 02:33:43 -0800 (PST) Received: from mtaomg-mb02.r1000.mx.aol.com (mtaomg-mb02.r1000.mx.aol.com [172.29.41.73]) by omr-m04.mx.aol.com (Outbound Mail Relay) with ESMTP id 366327013EF39 for ; Mon, 9 Dec 2013 05:33:38 -0500 (EST) Received: from core-dqa004a.r1000.mail.aol.com (core-dqa004.r1000.mail.aol.com [172.29.211.205]) by mtaomg-mb02.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id DCC45E000082 for ; Mon, 9 Dec 2013 05:33:37 -0500 (EST) References: <2FB752A4-27E7-484F-963F-3E46C565FBD7@apnic.net> <7ea3ab2ccbe54613b39f22a5613f9961@CO1PR05MB442.namprd05.prod.outlook.com> <02812A0C-6641-4F58-8E1C-3626AB4678F0@gmail.com> <529017a0a2894e0bb403317e020a318e@CO1PR05MB442.namprd05.prod.outlook.com> <529F5FFA.6000201@joelhalpern.com> To: lisp@ietf.org In-Reply-To: <529F5FFA.6000201@joelhalpern.com> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D0C2E141042D0B_C70_A73_webmail-d261.sysops.aol.com" X-Mailer: Webmail 38221-STANDARD Received: from 178.26.195.50 by webmail-d261.sysops.aol.com (205.188.16.112) with HTTP (WebMailUI); Mon, 09 Dec 2013 05:33:37 -0500 Message-Id: <8D0C2E140F84626-C70-2B7@webmail-d261.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Mon, 9 Dec 2013 05:33:37 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1386585218; bh=LnmG2QTuherHz6SbVv2aTM9cYEzg4Q6ZSpEdtDg/Slo=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=RNqVF6uUeN/AcX/5nPeVLp8yEDTSY7JBCN/i5oBf9d9405vWqWewiqGljf7BW08mr oBUYpcMYgHXiYXFBvL+ojFdwKacolR141+bWnW87pSYeLNLtIre99RrtXiJdfAs9U6 VG2+8Z+MxRPPGEjWJMX4uYrKRVBmJ2PGfnY4Ib50= x-aol-sid: 3039ac1d294952a59c813581 Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 09 Dec 2013 10:33:45 -0000 This is a multi-part message in MIME format. ----------MB_8D0C2E141042D0B_C70_A73_webmail-d261.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Sounds like a job for the NSA - collateral compensation included :-( Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Joel M. Halpern An: Ronald Bonica ; Dino Farinacci Cc: LISP mailing list list Verschickt: Mi, 4 Dez 2013 6:02 pm Betreff: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 A partial answer that has been suggested is that the oeprator who=20 deploys the PITR is an EID allocator rather than a conventional /=20 existing ISP. Unfortunately, if LISp succeeds it is not clear that the=20 compensation levels can match the increasing demand for traffic in the=20 critical periods. Yours, Joel On 12/4/13 11:51 AM, Ronald Bonica wrote: > Dino, > > I am not understanding your response. Let me ask the question another way= . > > Assume that an operator deploys a PITR. What policy can that operator enf= orce=20 to ensure that it is compensated for all (or even most) of the traffic that= it=20 carries across that PITR? > > = Ron > > >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, December 04, 2013 11:44 AM >> To: Ronald Bonica >> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list >> list >> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07 >> >>> Luigi, >>> >>> Is this really what is going to happen? >>> >>> If a PITR announces the entire /32 into the global Internet, it puts >> itself on the forwarding path for the entire /32, and incurs the cost >> associated with transporting traffic towards every site in that /32. >> This is supportable only if the PITR operator is somehow compensated >> for carrying all of that traffic. >> >> But maybe only from a few sources. But if the /32 needs to be divided >> based on region, then maybe /40s could be advertised. But to the point >> about "few sources", the more PITRs there are, the better the load is >> shared. >> >> And I envision PITRs will be deployed on on-path boxes anyways. Those >> boxes right now can route to the entire Internet, they are called PE >> boxes, are they not Ron? >> >>> Isn't it more likely that the PITR operator will advertise only >> slices of the /32, with each of those slices being assigned to either >> its customers (from whom it collects revenue) or the customers of other >> operators with whom it has made financial arrangements? >> >> No it won't be that way. EIDs are provider independent. If you do what >> we suggest, we make no forward progress. >> >> Dino >> >>> >>> Ron >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp =20 ----------MB_8D0C2E141042D0B_C70_A73_webmail-d261.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Sounds like a job for the N= SA - collateral compensation included :-(

Heiner


-----= Urspr=C3=BCngliche Mitteilung-----
Von: Joel M. Halpern <jmh@joelhalpern.com>
An: Ronald Bonica <rbonica@juniper.net>; Dino Farinacci <farinacci= @gmail.com>
Cc: LISP mailing list list <lisp@ietf.org>
Verschickt: Mi, 4 Dez 2013 6:02 pm
Betreff: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07

A partial answer that has been suggested=
 is that the oeprator who=20
deploys the PITR is an EID allocator rather than a conventional /=20
existing ISP.  Unfortunately, if LISp succeeds it is not clear that the=20
compensation levels can match the increasing demand for traffic in the=20
critical periods.

Yours,
Joel

On 12/4/13 11:51 AM, Ronald Bonica wrote:
> Dino,
>
> I am not understanding your response. Let me ask the question another =
way.
>
> Assume that an operator deploys a PITR. What policy can that operator =
enforce=20
to ensure that it is compensated for all (or even most) of the traffic that=
 it=20
carries across that PITR?
>
>                                                                       =
   Ron
>
>
>> -----Original Message-----
>> From: Dino Farinacci [mail=
to:farinacci@gmail.com]
>> Sent: Wednesday, December 04, 2013 11:44 AM
>> To: Ronald Bonica
>> Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing lis=
t
>> list
>> Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07
>>
>>> Luigi,
>>>
>>> Is this really what is going to happen?
>>>
>>> If a PITR announces the entire /32 into the global Internet, i=
t puts
>> itself on the forwarding path for the entire /32, and incurs the c=
ost
>> associated with transporting traffic towards every site in that /3=
2.
>> This is supportable only if the PITR operator is somehow compensat=
ed
>> for carrying all of that traffic.
>>
>> But maybe only from a few sources. But if the /32 needs to be divi=
ded
>> based on region, then maybe /40s could be advertised. But to the p=
oint
>> about "few sources", the more PITRs there are, the better the load=
 is
>> shared.
>>
>> And I envision PITRs will be deployed on on-path boxes anyways. Th=
ose
>> boxes right now can route to the entire Internet, they are called =
PE
>> boxes, are they not Ron?
>>
>>> Isn't it more likely that the PITR operator will advertise onl=
y
>> slices of the /32, with each of those slices being assigned to eit=
her
>> its customers (from whom it collects revenue) or the customers of =
other
>> operators with whom it has made financial arrangements?
>>
>> No it won't be that way. EIDs are provider independent. If you do =
what
>> we suggest, we make no forward progress.
>>
>> Dino
>>
>>>
>>>                                                       Ron
>>>
>>>
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>>
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>
_______________________________________________
lisp mailing list
lisp@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/lisp
----------MB_8D0C2E141042D0B_C70_A73_webmail-d261.sysops.aol.com-- From fcoras@ac.upc.edu Mon Dec 9 06:12:42 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8417F1AE2E1 for ; Mon, 9 Dec 2013 06:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq9rUblb8Sfx for ; Mon, 9 Dec 2013 06:12:38 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 460D01ADF7F for ; Mon, 9 Dec 2013 06:12:38 -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 rB9ECV43014820; Mon, 9 Dec 2013 15:12:31 +0100 Received: from [10.8.0.22] (gw-3-vpn-i.ac.upc.es [147.83.35.77]) by gw.ac.upc.edu (Postfix) with ESMTP id 0F4766B0284; Mon, 9 Dec 2013 15:10:15 +0100 (CET) Message-ID: <52A5CFCC.7090802@ac.upc.edu> Date: Mon, 09 Dec 2013 15:12:28 +0100 From: Florin Coras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: lisp@ietf.org References: <529F9088.8060504@ac.upc.edu> In-Reply-To: <529F9088.8060504@ac.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 09 Dec 2013 14:12:42 -0000 Apologies for the belated reply. The paper Albert was referring to can be found at [1]. Florin [1] http://arxiv.org/pdf/1312.1378v2.pdf On 12/04/2013 09:28 PM, Albert Cabellos wrote: > Hi > > I went through the document in detail and IMHO it is well structured and > more importantly, it provides a complete and meticulous analysis of the > security threats of LISP on a public deployment. > Below you can find some comments: > > Regards > > Albert > > > * Section 4.2->In addition to the attacks described in this section > end-hosts behind an ITR could use the data-plane to overflow the ITR's > Map-Cache by sending packets to non-popular EID prefixes (pretty much as > a scan attack but with a different goal). In this scenario the xTR may > evict entries from the map-cache that are popular (and in-use) and > disrupt the normal > operation of the network by forcing flows to miss. Florin will send a > paper describing and analyzing > in detail the attack and its impact on cache performance. From acabello@ac.upc.edu Mon Dec 9 08:01:25 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48431AE2B6 for ; Mon, 9 Dec 2013 08:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GoKZNMAchLm for ; Mon, 9 Dec 2013 08:01:24 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id BA6FB1AE2DF for ; Mon, 9 Dec 2013 08:01:23 -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 rB9G0tZL019100; Mon, 9 Dec 2013 17:00:55 +0100 Received: from [192.168.0.200] (unknown [46.27.20.114]) by gw.ac.upc.edu (Postfix) with ESMTP id 31BCC6B0284; Mon, 9 Dec 2013 16:58:40 +0100 (CET) Message-ID: <52A5E936.6010001@ac.upc.edu> Date: Mon, 09 Dec 2013 17:00:54 +0100 From: Albert Cabellos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Damien Saucez References: <529F9088.8060504@ac.upc.edu> <91805CE8-01CC-4F6D-945F-D98D23A3F179@gmail.com> <52A05BC6.9080008@ac.upc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LISP mailing list list Subject: Re: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 09 Dec 2013 16:01:25 -0000 Hi, On 06/12/2013 0:05, Damien Saucez wrote: [snip] >> Right, thanks. What about recommending that each nonce should be used >> at least once? So that a nonce canīt be overwritten if it has not >> been used. >> > > Isn't that the definition of a nonce? I don't see how it helps. > > Imagine > > - Legit sends Nonce1 > - Bad guy sends Nonce2 with spoof address of Legit > - Nonce1 arrives, but it is too late, it has been overridden by Nonce2 > already so the return with Nonce1is just ignored. > Ok thanks! Albert From internet-drafts@ietf.org Mon Dec 9 14:01:11 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AFC1AE522; Mon, 9 Dec 2013 14:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdWelCw3zo4n; Mon, 9 Dec 2013 14:01:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C65A1AE5CD; Mon, 9 Dec 2013 14:01:07 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209220107.1439.909.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 14:01:07 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: 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, 09 Dec 2013 22:01:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP Network Element Deployment Considerations Author(s) : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-11.txt Pages : 28 Date : 2013-12-09 Abstract: This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since. This memo represents one stable point in that evolution of understanding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-deployment-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-deployment-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@bartschnet.de Tue Dec 17 01:06:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C8E1AE026 for ; Tue, 17 Dec 2013 01:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDanj1XD3_Fm for ; Tue, 17 Dec 2013 01:06:35 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id 51D731AE0CA for ; Tue, 17 Dec 2013 01:06:35 -0800 (PST) Received: from [95.117.72.60] (helo=nas.bartschnet.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Vsqbm-0003Wf-8C for lisp@ietf.org; Tue, 17 Dec 2013 10:06:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_bed183157165cfd7dc2e9185df39db22" Date: Tue, 17 Dec 2013 10:06:29 +0100 From: Rene Bartsch To: lisp@ietf.org Message-ID: <747ee9d2c7e75e5f5bcc770e77d40864@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/0.9.5 X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: [lisp] LISP as routing protocol in MESH networks X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 17 Dec 2013 09:06:37 -0000 --=_bed183157165cfd7dc2e9185df39db22 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, I've decided to use NROffEdit for writing my CGEID draft (Cryptographically Generated Endpoint IDentifiers). While considering CGEIDs I got another idea: Would it be possible to use LISP as routing protocol for mesh networks by announcing the CGEIDs of neighbour-nodes as RLOCs of a node? It would be some kind of onion routing without encryption. The biggest problem of a node seems to be reaching the map-servers/-resolvers when bootstrapping. Can a LISP tunnel router/mobile node run it's own map-server/-resolver connecting directly to the Tier 1 map-server mesh or is there some kind of authentication between the map-servers? Regards, Renne -- Best regards, Rene Bartsch, B. Sc. Informatics Current Bitcoin Exchange Rate: https://www.bitcoin.de/de/r/mwfngu --=_bed183157165cfd7dc2e9185df39db22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

I've decided to use NROffEdit for writing my CGEID draft (Cryptographica= lly Generated Endpoint IDentifiers).

While considering CGEIDs I got another idea:

Would it be possible to use LISP as routing protocol for mesh networks b= y announcing the CGEIDs of neighbour-nodes as RLOCs of a node? It would be = some kind of onion routing without encryption.

The biggest problem of a node seems to be reaching the map-servers/-reso= lvers when bootstrapping. Can a LISP tunnel router/mobile node run it's own= map-server/-resolver connecting directly to the Tier 1 map-server mesh or = is there some kind of authentication between the map-servers?

 

Regards,

Renne

 

-- 
Best regards,

Rene Bartsch, B. Sc. Informatics



Current Bitcoin Exchange Rate: https://www.bitcoin.de/de/r/mwfngu
--=_bed183157165cfd7dc2e9185df39db22-- From lori@lispmob.org Tue Dec 17 02:50:01 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6D81AE0A7 for ; Tue, 17 Dec 2013 02:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6RI03CR-dBU for ; Tue, 17 Dec 2013 02:50:00 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08C1AD8F9 for ; Tue, 17 Dec 2013 02:49:59 -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 rBHAnu6h026477; Tue, 17 Dec 2013 11:49:56 +0100 Received: from dhcp-10-61-107-160.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) by gw.ac.upc.edu (Postfix) with ESMTP id E5DC46B01C1; Tue, 17 Dec 2013 11:47:22 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_430115B6-1007-4745-B1EF-0E74C04A52FC" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Lori Jakab In-Reply-To: <747ee9d2c7e75e5f5bcc770e77d40864@bartschnet.de> Date: Tue, 17 Dec 2013 12:49:53 +0200 Message-Id: References: <747ee9d2c7e75e5f5bcc770e77d40864@bartschnet.de> To: Rene Bartsch X-Mailer: Apple Mail (2.1510) Cc: lisp@ietf.org Subject: Re: [lisp] LISP as routing protocol in MESH networks X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 17 Dec 2013 10:50:02 -0000 --Apple-Mail=_430115B6-1007-4745-B1EF-0E74C04A52FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Rene, On Dec 17, 2013, at 11:06 AM, Rene Bartsch wrote: [=85] > The biggest problem of a node seems to be reaching the = map-servers/-resolvers when bootstrapping. Can a LISP tunnel = router/mobile node run it's own map-server/-resolver connecting directly = to the Tier 1 map-server mesh or is there some kind of authentication = between the map-servers? >=20 There is no authentication for querying the DDT root nodes. Just like = with DNS, it is possible for a node to maintain a list with the root = nodes and query iteratively for an EID, starting at the root. It may not = be the fattest way, but it solves your bootstrapping problem. The next = version of LISPmob (0.3.4) will support this mode of operation. AFAIK, = no other implementation supports it though. HTH, -Lori= --Apple-Mail=_430115B6-1007-4745-B1EF-0E74C04A52FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Rene,

On Dec 17, 2013, at 11:06 AM, Rene Bartsch = <ietf@bartschnet.de> = wrote:

[=85]

The biggest = problem of a node seems to be reaching the map-servers/-resolvers when = bootstrapping. Can a LISP tunnel router/mobile node run it's own = map-server/-resolver connecting directly to the Tier 1 map-server mesh = or is there some kind of authentication between the = map-servers?


There = is no authentication for querying the DDT root nodes.  Just like = with DNS, it is possible for a node to maintain a list with the root = nodes and query iteratively for an EID, starting at the root. It may not = be the fattest way, but it solves your bootstrapping problem.  The = next version of LISPmob (0.3.4) will support this mode of operation. =  AFAIK, no other implementation supports it = though.

HTH,
-Lori
= --Apple-Mail=_430115B6-1007-4745-B1EF-0E74C04A52FC-- From farinacci@gmail.com Tue Dec 17 07:31:15 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A118E1AE168 for ; Tue, 17 Dec 2013 07:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRagWyAOUI74 for ; Tue, 17 Dec 2013 07:31:13 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B244B1AE14F for ; Tue, 17 Dec 2013 07:31:13 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id g10so6932653pdj.29 for ; Tue, 17 Dec 2013 07:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fZgFusIi5vGuKujRJSYJBGQ1Q9t1RO6CXsoo1ptCyjo=; b=Nf+n4OqkHVGASx77xdDDzIB0Lu1zRxIYUEoQpY8Xr9+P+S8FiLp0TkEsl0YebGB+x2 1JuGBXZlTGewZ6JY12Ub8RDEWVqGDHkkTOZtW+fu7KF4NLDRg4FVqw/0asQ8NGNR5yme rb8SanLa05TfFX6m4Iz2OmlMg9vT7mCNKcv+Ly/U+V0cWW8hjAO3gG0opsg1HW2hZzz8 ThEzFhnsvR55rZg9K+qdWH0+R3TdEJ+a+1riSatil6VTLixGsYOzXXtw/hKcVu0LPWvV WhZ7F+lsxwncRWADH/GCDqXf3LWWzcMTOoRjJhWOxC1fg9hxncdcxdspCDTq8bGf3HHP 7R4A== X-Received: by 10.68.196.193 with SMTP id io1mr28294837pbc.46.1387294272708; Tue, 17 Dec 2013 07:31:12 -0800 (PST) Received: from [192.168.1.166] ([207.145.253.66]) by mx.google.com with ESMTPSA id ka3sm34655032pbc.32.2013.12.17.07.31.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Dec 2013 07:31:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <747ee9d2c7e75e5f5bcc770e77d40864@bartschnet.de> Date: Tue, 17 Dec 2013 07:31:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7B4F80D2-3DC5-4261-8525-07489FE6272D@gmail.com> References: <747ee9d2c7e75e5f5bcc770e77d40864@bartschnet.de> To: Rene Bartsch X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] LISP as routing protocol in MESH networks X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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, 17 Dec 2013 15:31:15 -0000 Hi, >=20 > I've decided to use NROffEdit for writing my CGEID draft = (Cryptographically Generated Endpoint IDentifiers). >=20 > While considering CGEIDs I got another idea: >=20 > Would it be possible to use LISP as routing protocol for mesh networks = by announcing the CGEIDs of neighbour-nodes as RLOCs of a node? It would = be some kind of onion routing without encryption. I would think you would want RLOCs to continue to be Provider-Assigned = addresses and thet CGEIDs are just like any other EID. That is, the = CGEID's topological location could be found by doing a mapping database = lookup. But yes, I have seen use-cases where folks want tunnel-endpoints to be = mobile. And if you want to find a new location of the tunnel end-point, = then you assign the tunnel-endpoint an EID. So let me be more precise in = my language. The requirement was to make a GRE tunnel mobile. So if you = configured the ends of a GRE tunnel to be in EID-space, either end could = move if those EIDs mapped to locators, and LISP encapsulation is = performed to an xTR adjacent to the GRE end-point or co-located with the = GRE end-point. We have also see LISP use to make a routing protocol work over a = wide-area network where multi-hop adjacencies were formed. cisco's EIGRP = is doing this in some use-cases. > The biggest problem of a node seems to be reaching the = map-servers/-resolvers when bootstrapping. Can a LISP tunnel = router/mobile node run it's own map-server/-resolver connecting directly = to the Tier 1 map-server mesh or is there some kind of authentication = between the map-servers? Yes, there are military applications that want to do this as well. Dino >=20 > =20 > Regards, >=20 > Renne >=20 > =20 > --=20 > Best regards, >=20 > Rene Bartsch, B. Sc. Informatics >=20 >=20 >=20 > Current Bitcoin Exchange Rate: https://www.bitcoin.de/de/r/mwfngu >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp