From nobody Fri May 1 15:59:42 2015 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 646541A6FEB; Fri, 1 May 2015 15:59:40 -0700 (PDT) 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 68iRpDXE_Va2; Fri, 1 May 2015 15:59:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFBB1A6F32; Fri, 1 May 2015 15:59:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150501225938.17488.33586.idtracker@ietfa.amsl.com> Date: Fri, 01 May 2015 15:59:38 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-01.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: Fri, 01 May 2015 22:59:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Data-Plane Confidentiality Authors : Dino Farinacci Brian Weis Filename : draft-ietf-lisp-crypto-01.txt Pages : 16 Date : 2015-05-01 Abstract: This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-crypto-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-crypto-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 1 16:04:08 2015 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 28A8C1B2E75 for ; Fri, 1 May 2015 16:04:07 -0700 (PDT) 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 LF8t84OSw4hD for ; Fri, 1 May 2015 16:04:05 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C401B2EB6 for ; Fri, 1 May 2015 16:04:05 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so103357925pab.3 for ; Fri, 01 May 2015 16:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=O4j/CYbmi41cgzg3rnuXLWataOiIGgDMECMqF3hfoaI=; b=IjZok9jshRpqt2C8/hHAFMhdUZ+pyUWhukyMPgQwR5GxWfpVatJADO5Y7q5H105PST zpYsl+KPW1WnYL0jVBNMkRTHYUoxfTzz6rLhz854rFf6xhESe8I9Wyd2+YjPPcmHx+rB evqdCc7wPGwKZDzIHzg+xk1VMTFWHyLVEudAcm01yfA50ut3OtPuCBnx+ZJV2v77TIAt KXmK4nh75DskqheFNGfs0AQama5u1zWHHUFMQdpTOY1WZ6QwX7qUNeTrcR6GSjcilrcb cJC5x5GNXZS/B6P4T8+5n0A0ue47qcjXkZqqj8MPIp85EnWnZlkZ8U28fNfaXLgSQOm1 IV7Q== X-Received: by 10.68.107.97 with SMTP id hb1mr21648463pbb.122.1430521444679; Fri, 01 May 2015 16:04:04 -0700 (PDT) Received: from ?IPv6:2601:9:4701:1df0:c4f4:ec3b:4dfc:be74? ([2601:9:4701:1df0:c4f4:ec3b:4dfc:be74]) by mx.google.com with ESMTPSA id pa1sm5811559pdb.73.2015.05.01.16.04.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 May 2015 16:04:04 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2015 16:04:03 -0700 References: <20150501225938.17488.33586.idtracker@ietfa.amsl.com> To: LISP mailing list list Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-crypto-01.txt 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, 01 May 2015 23:04:07 -0000 Folks, this draft contains the following changes: B.1. Changes to draft-ietf-lisp-crypto-01.txt o Posted May 2015. o Create cipher suites and encode them in the Security LCAF. o Add IV to beginning of packet header and ICV to end of packet. o AEAD procedures are now part of encryption process. And are based on detail security expert comments from Watson Ladd and = Ilari Liusvaara. Not to mention a new co-author Brian Weis, who has been = working on security standards in the IETF and building security products = for well over a decade. I have done a prototype to test out IV and ICVs and tend to do a full = xTR implementation starting next week. I have also experimented with = different Elliptic-Curve Diffie-Hellman groups and will do CPU = utilization comparisons. Thanks, Dino > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-01.txt > Date: May 1, 2015 at 3:59:38 PM PDT > To: > Cc: lisp@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol = Working Group of the IETF. >=20 > Title : LISP Data-Plane Confidentiality > Authors : Dino Farinacci > Brian Weis > Filename : draft-ietf-lisp-crypto-01.txt > Pages : 16 > Date : 2015-05-01 >=20 > Abstract: > This document describes a mechanism for encrypting LISP encapsulated > traffic. The design describes how key exchange is achieved using > existing LISP control-plane mechanisms as well as how to secure the > LISP data-plane from third-party surveillance attacks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lisp-crypto-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-crypto-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sat May 2 00:23:00 2015 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 8B0681A1A79 for ; Sat, 2 May 2015 00:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5cV33CiY17nz for ; Sat, 2 May 2015 00:22:57 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9A81A1A64 for ; Sat, 2 May 2015 00:22:57 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id DDD2F1A25C9; Sat, 2 May 2015 10:22:54 +0300 (EEST) Date: Sat, 2 May 2015 10:22:54 +0300 From: Ilari Liusvaara To: Dino Farinacci Message-ID: <20150502072254.GA6857@LK-Perkele-VII> References: <20150501225938.17488.33586.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Fwd: I-D Action: draft-ietf-lisp-crypto-01.txt 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: Sat, 02 May 2015 07:22:59 -0000 On Fri, May 01, 2015 at 04:04:03PM -0700, Dino Farinacci wrote: > Folks, this draft contains the following changes: > > B.1. Changes to draft-ietf-lisp-crypto-01.txt > > o Posted May 2015. > > o Create cipher suites and encode them in the Security LCAF. > > o Add IV to beginning of packet header and ICV to end of packet. > > o AEAD procedures are now part of encryption process. At least I can follow how the algorithms work. Remaining issues/notes: - It composes AEAD mode instaed of using ready-made one. The composed mode is if nothing else slow (SHA-1 is already slower than some ready-made AEAD modes). - Key derivation looks to be missing hashing in important parameters (like group and exchange keys) into secrets. - Some NIST-spec KDF? I think there are RFCs that describe KDFs. - 1024-bit DH is regarded as quite weak nowadays. - Two new ECDH functions from CFRG were recently annouced[1]. Should be faster than DH1024/DH2048 with way smaller keys. [1] The lower security one (Curve25519, as is): v^2 = u^3 + 486662u^2 + u (mod 2^255-19) Secret key size: 255 bits. Secret key masking: Bits 0, 1, 2 off, bit 254 on. Point encoding: u as 32-octet little-endian base-256 integer. Base point: u=9. The higher security one: v^2 = u^3 + 156326u^2 + u (mod 2^448-2^224-1) Secret key size: 448 bits. Secret key masking: Bits 0, 1 off, bit 447 on. Point encoding: u as 56-octet little-endian base-256 integer. Base point: u=5. From nobody Mon May 4 23:47:02 2015 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 D405F1B2E17 for ; Mon, 4 May 2015 23:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LgHWvzvzooMs for ; Mon, 4 May 2015 23:46:59 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BA91ACD23 for ; Mon, 4 May 2015 23:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2808; q=dns/txt; s=iport; t=1430808418; x=1432018018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eOyKV1Kd/GLKX2zV1FcyJwb/5V3k0R1JcsvkdXN5xvY=; b=Rdao64Xugr0XIxbSc07nJfA8Vk/tyqcSh9QlCvf/tXSgq1xaq03piWTi uBo1sz1062lBULR/+uc3/mDj0H+z6m+cyVC2pfKZ05Lqmb5Rzn78l5Gxt 6d52j06W28q8CIKMACUrAyUaPWadWFaSM9AeBrRoXV407GzbQqlxDzC40 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQBAAkZ0hV/5BdJa1ZA4MMU1wFxXQJgUwKhgUCgTA4FAEBAQEBAQGBCoQgAQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FiCMIDcUbAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOYQiEQEeIxAHEYMGgRYFj2KCK4pSgSSRKINSI4N0b4ELOYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,371,1427760000"; d="scan'208";a="147095448" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP; 05 May 2015 06:46:57 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t456kvTT012558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 May 2015 06:46:57 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.236]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 5 May 2015 01:46:57 -0500 From: "Brian Weis (bew)" To: Ilari Liusvaara Thread-Topic: [lisp] I-D Action: draft-ietf-lisp-crypto-01.txt Thread-Index: AQHQhv9Hck/XYqgwoEKHOlxO6G+Ctw== Date: Tue, 5 May 2015 06:46:57 +0000 Message-ID: References: <20150501225938.17488.33586.idtracker@ietfa.amsl.com> <20150502072254.GA6857@LK-Perkele-VII> In-Reply-To: <20150502072254.GA6857@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.211] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2F635D83112B40438086450900989EFD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] I-D Action: draft-ietf-lisp-crypto-01.txt 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, 05 May 2015 06:47:01 -0000 Hi Ilari, Thanks for your comments. On May 2, 2015, at 12:22 AM, Ilari Liusvaara = wrote: > On Fri, May 01, 2015 at 04:04:03PM -0700, Dino Farinacci wrote: >> Folks, this draft contains the following changes: >>=20 >> B.1. Changes to draft-ietf-lisp-crypto-01.txt >>=20 >> o Posted May 2015. >>=20 >> o Create cipher suites and encode them in the Security LCAF. >>=20 >> o Add IV to beginning of packet header and ICV to end of packet. >>=20 >> o AEAD procedures are now part of encryption process. >=20 > At least I can follow how the algorithms work. Remaining issues/notes: > - It composes AEAD mode instaed of using ready-made one. The composed > mode is if nothing else slow (SHA-1 is already slower than some > ready-made AEAD modes). These are the algorithms we=92re comfortable with for now. We could have specified the combined AEAD mode cipher modes, but they add complexity in the form of maintaining a counter for the nonce. > - Key derivation looks to be missing hashing in important parameters > (like group and exchange keys) into secrets. Not sure which parameters you mean? The DH shared secret is the key for the KDF, I=92m not sure why we=92d provide any other keys as input= =20 to the KDF. > - Some NIST-spec KDF? I think there are RFCs that describe KDFs. Yes, there=92s RFC 5869 but the NIST KDFs are also widely used. > - 1024-bit DH is regarded as quite weak nowadays. > - Two new ECDH functions from CFRG were recently annouced[1]. > Should be faster than DH1024/DH2048 with way smaller keys. We do need less computationally demanding ciphers for deices that do crypto in ARM based platforms, which explains the 1024-bit DH (and yes, we realize it is weak). As stated in the Future Work section we will be looking at these ECDH functions and should have some results before the Prague meeting. If we can replace the 1024-bit DH we will. Thanks, Brian >=20 >=20 >=20 >=20 > [1] >=20 > The lower security one (Curve25519, as is): >=20 > v^2 =3D u^3 + 486662u^2 + u (mod 2^255-19) >=20 > Secret key size: 255 bits. > Secret key masking: Bits 0, 1, 2 off, bit 254 on. > Point encoding: u as 32-octet little-endian base-256 integer. > Base point: u=3D9. >=20 > The higher security one: >=20 > v^2 =3D u^3 + 156326u^2 + u (mod 2^448-2^224-1) >=20 > Secret key size: 448 bits. > Secret key masking: Bits 0, 1 off, bit 447 on. > Point encoding: u as 56-octet little-endian base-256 integer. > Base point: u=3D5. >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Thu May 7 05:28:41 2015 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 8F7351A88D7; Thu, 7 May 2015 05:28:39 -0700 (PDT) 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 PZp03ssWe7NB; Thu, 7 May 2015 05:28:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D591A88D2; Thu, 7 May 2015 05:28:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150507122830.13542.21249.idtracker@ietfa.amsl.com> Date: Thu, 07 May 2015 05:28:30 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-impact-02.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: Thu, 07 May 2015 12:28:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Impact Authors : Damien Saucez Luigi Iannone Albert Cabellos Florin Coras Filename : draft-ietf-lisp-impact-02.txt Pages : 16 Date : 2015-05-07 Abstract: The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet scalability properties leveraging on three simple principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the Internet in general and the end-user in particular. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-impact-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-impact-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 7 05:31:32 2015 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 9492F1A88DE for ; Thu, 7 May 2015 05:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 WbR3lh-6hM24 for ; Thu, 7 May 2015 05:31:29 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A751A88C5 for ; Thu, 7 May 2015 05:31:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,384,1427752800"; d="scan'208";a="114873489" Received: from eduroam-160a.sophia.inria.fr ([193.51.208.160]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 07 May 2015 14:31:27 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: <20150507122830.13542.98562.idtracker@ietfa.amsl.com> Date: Thu, 7 May 2015 14:31:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62B10AE2-D4AA-4172-A781-F9D7A74232DF@inria.fr> References: <20150507122830.13542.98562.idtracker@ietfa.amsl.com> To: LISP mailing list list X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [lisp] New Version Notification for draft-ietf-lisp-impact-02.txt 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, 07 May 2015 12:31:31 -0000 Dear all,=20 In this last version we addressed the various comments we got on the = mailing list and during the last meeting. Please comment the changes. If it is ok, we would like to renew our = demand for last call. Thank you, Damien Saucez=20 On 07 May 2015, at 14:28, internet-drafts@ietf.org wrote: >=20 > A new version of I-D, draft-ietf-lisp-impact-02.txt > has been successfully submitted by Luigi Iannone and posted to the > IETF repository. >=20 > Name: draft-ietf-lisp-impact > Revision: 02 > Title: LISP Impact > Document date: 2015-05-07 > Group: lisp > Pages: 16 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lisp-impact-02.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ > Htmlized: https://tools.ietf.org/html/draft-ietf-lisp-impact-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-impact-02 >=20 > Abstract: > The Locator/Identifier Separation Protocol (LISP) aims at improving > the Internet scalability properties leveraging on three simple > principles: address role separation, encapsulation, and mapping. In > this document, based on implementation work, deployment experiences, > and theoretical studies, we discuss the impact that the deployment = of > LISP can have on both the Internet in general and the end-user in > particular. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Thu May 14 12:44:02 2015 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 B45AC1A8A27 for ; Thu, 14 May 2015 12:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 2OEzIln7i7U3 for ; Thu, 14 May 2015 12:43:59 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5AB1A8A95 for ; Thu, 14 May 2015 12:43:35 -0700 (PDT) Received: by wizk4 with SMTP id k4so255046132wiz.1 for ; Thu, 14 May 2015 12:43:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:cc:to; bh=Bgsu/sCqwhcNDWWOt5Kb0L6Wy8BB+zY3+AJ4R7gM6IU=; b=CpBD7d1leB21TxNDd9XM+/n9otTgRUVCMsGVWQ+8+XFGCw0l88cZnibIq4SXtDRAYG YUzml2kU8IUSyvGG23JgIc92VIY9vhfwjayYjH4wZuZiyw3jBTCVAf9L8LaRHEH2pSo0 UhtlnVSexadvBFkdDglzdDW3OqE+nQpevJPXFmes269j5tFZeweMiAry1IQxEwUF2kFQ ZeE1zseBjddzKRpnXuHuLDdw7hoCxGATbxa0DvTyZmcAAsv4cQfaE+aJVVmLYHJN23k5 EVfk8ur4LUhxbjoGkHHGC+dTp5j4rBupbjRzWp/oFbGb0Cjw6OT99y8f0NiIi2/UgnCh oNgg== X-Gm-Message-State: ALoCoQk1ON7HAghLbIrziuHMeYVXUXqJ9PSxrQgwb7qk6gR01kiIEi2xc1KqXEJh4m5an2vtbApr X-Received: by 10.180.88.169 with SMTP id bh9mr31030083wib.6.1431632614585; Thu, 14 May 2015 12:43:34 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:458:48c:658e:ae0c? ([2a01:e35:1381:3430:458:48c:658e:ae0c]) by mx.google.com with ESMTPSA id m2sm5657283wiy.7.2015.05.14.12.43.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 12:43:33 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_DC5E681F-E906-45B0-B740-8E8000536E04" Message-Id: <0D77C474-57FB-4042-8A8B-B5AF4C135ED4@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Thu, 14 May 2015 21:43:33 +0200 References: To: LISP mailing list list X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Joel Halpern Direct Subject: [lisp] WG Last Call draft-ietf-lisp-impact-02 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, 14 May 2015 19:44:00 -0000 --Apple-Mail=_DC5E681F-E906-45B0-B740-8E8000536E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, the authors of the LISP Impact document = [https://tools.ietf.org/id/draft-ietf-lisp-impact-02.txt] submitted a new version of the draft and requested the Work Group Last = Call. This email starts a WG Last Call, to end May 28th, 2015. Please review this updated WG document and let the WG know if you agree = that it is ready for handing to the AD. If you have objections, please state your reasons why, and explain what = it would take to address your concerns. Thanks Luigi & Joel --Apple-Mail=_DC5E681F-E906-45B0-B740-8E8000536E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi All,

the authors of the LISP Impact document =  [https://tools.ietf.org/id/draft-ietf-lisp-impact-02.txt]
submitted a new version of the draft and requested = the Work Group Last Call.

This email = starts a WG Last Call, to end May 28th, 2015.

Please review this = updated WG document and let the WG know if you agree that it is ready = for handing to the AD.
If you have = objections, please state your reasons why, and explain what it would = take to address your concerns.

Thanks

Luigi & Joel


= --Apple-Mail=_DC5E681F-E906-45B0-B740-8E8000536E04-- From nobody Tue May 19 00:24:44 2015 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 C2A001ACDBE; Tue, 19 May 2015 00:24:42 -0700 (PDT) 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 fzsSIn7hRBlA; Tue, 19 May 2015 00:24:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFDC1AC436; Tue, 19 May 2015 00:24:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150519072441.8211.22894.idtracker@ietfa.amsl.com> Date: Tue, 19 May 2015 00:24:41 -0700 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-12.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: Tue, 19 May 2015 07:24:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP EID Block Authors : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-12.txt Pages : 16 Date : 2015-05-19 Abstract: This is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-eid-block-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-block-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 27 14:47:16 2015 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 D34BD1ACCFF for ; Wed, 27 May 2015 14:47:15 -0700 (PDT) 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 NIptI1WIrWe7 for ; Wed, 27 May 2015 14:47:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CAEA1ACCFC for ; Wed, 27 May 2015 14:47:10 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1431.namprd05.prod.outlook.com (25.160.107.153) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 21:46:51 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0172.012; Wed, 27 May 2015 21:46:52 +0000 From: Ross Callon To: Luigi Iannone , LISP mailing list list Thread-Topic: [lisp] WG Last Call draft-ietf-lisp-impact-02 Thread-Index: AQHQjn5bZ9e6Ul6hM0e5dxjOHTDbvp2QYL0w Date: Wed, 27 May 2015 21:46:51 +0000 Message-ID: References: <0D77C474-57FB-4042-8A8B-B5AF4C135ED4@gigix.net> In-Reply-To: <0D77C474-57FB-4042-8A8B-B5AF4C135ED4@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-originating-ip: [66.129.241.13] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1431; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BY1PR0501MB1431; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1431; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(53754006)(51444003)(164054003)(86362001)(19617315012)(19580395003)(106356001)(77156002)(122556002)(102836002)(15975445007)(68736005)(74316001)(19580405001)(19300405004)(2900100001)(40100003)(19609705001)(46102003)(16236675004)(50986999)(62966003)(2950100001)(92566002)(33656002)(99286002)(76176999)(97736004)(5001830100001)(87936001)(5001860100001)(2656002)(4001540100001)(81156007)(5001920100001)(101416001)(107886002)(66066001)(64706001)(230783001)(54356999)(105586002)(19625215002)(106116001)(189998001)(76576001)(5002640100001)(5001960100002)(5001770100001)(18717965001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1431; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB14309BCF3B5608CF53D75DC7A5CB0BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 21:46:51.7954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1431 Archived-At: Cc: Joel Halpern Direct Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-02 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, 27 May 2015 21:47:16 -0000 --_000_BY1PR0501MB14309BCF3B5608CF53D75DC7A5CB0BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The document seems much improved. I still have three issues which should be= corrected before the document is ready for publication. Section 1, last paragraph, second sentence. This currently reads: There still are many, economical rather than technical, open questions = related to the deployment of such infrastructure. However, it is clear that there are both economical and technical issues. A= s examples of technical issues, later in the document (section 5.2) talks a= bout the difficulty in troubleshooting, and states "...the major issue that= years of LISP experimentation have shown is the difficulty of troubleshoot= ing. When there is a problem in the network, it is hard to pin-point the r= eason as the operator only has a partial view of the network". This is of c= ourse one example of a technical issue (another related one is my next comm= ent below). Thus I think that it would be correct to change this sentence t= o state: There still are many, economical and technical, open questions related = to the deployment of such infrastructure. This might have been lost in the vigorous discussion of other issues which = occurred during the first WGLC, however, my comments from the previous WGLC= included one point which has not been addressed. This comment was: > Finally, perhaps I missed it but I didn't see any discussion of the > volume of overhead related to OAM traffic used for liveness detection > (the need for ITR's to determine the reachability of ETR's). I still think that we need discussion of the overhead related to OAM traffi= c. If this is not known, it might be appropriate simply to add to the secon= d paragraph of section 1 something along the lines of: The overhead related to OAM traffic (for example, for liveness detectio= n) is not known. Also, in section 3, first bullet after the first paragraph, the document cu= rrently states: o EID-to-RLOC mappings follow the same prefix size as the current BGP routing infrastructure; In email in our earlier discussion Florin Coras stated: > The goal our experiments was to understand the > performance of LISP map-caches if edge > networks already owning their address space (PI address owners) were to > switch to LISP. Speculating if and how PA owning edge networks are to > switch to LISP was outside the scope. I think that these two points are saying the same thing. However, I am not = sure whether most (or all) readers will understand that the bullet point in= the current document implies the point that Florin made in his email. We c= ould clarify this in the next paragraph as follows: OLD The above assumptions are inline with [RFC7215] and current LISP deployments, however, such situation may change in the long term. Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space sizes, still showing results that are consitent and equivalent to the above assumptions. NEW The above assumptions are in line with [RFC7215] and current LISP deployments, however, such situation may change in the long term. For example, the first bullet above assumes that only edge networks already owning their address space (current PI address owners) will switch to LISP. Speculating whether and how PA owning edge networks might switch to LISP was outside the scope. Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space sizes, still showing results that are consistent and equivalent to the above assumptions. Thanks, Ross From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone Sent: Thursday, May 14, 2015 3:44 PM To: LISP mailing list list Cc: Joel Halpern Direct Subject: [lisp] WG Last Call draft-ietf-lisp-impact-02 Hi All, the authors of the LISP Impact document [https://tools.ietf.org/id/draft-i= etf-lisp-impact-02.txt] submitted a new version of the draft and requested the Work Group Last Call= . This email starts a WG Last Call, to end May 28th, 2015. Please review this updated WG document and let the WG know if you agree tha= t it is ready for handing to the AD. If you have objections, please state your reasons why, and explain what it = would take to address your concerns. Thanks Luigi & Joel --_000_BY1PR0501MB14309BCF3B5608CF53D75DC7A5CB0BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The document seems much i= mproved. I still have three issues which should be corrected before the doc= ument is ready for publication.

 <= /p>

 <= /p>

Section 1, last paragraph= , second sentence. This currently reads:

 <= /p>

    There = still are many, economical rather than technical, open questions related to=

    the de= ployment of such infrastructure.

 <= /p>

However, it is clear that= there are both economical and technical issues. As examples of technical i= ssues, later in the document (section 5.2) talks about the difficulty in troubleshooting, and states “…the major issue th= at years of LISP experimentation have shown is the difficulty of troublesho= oting.  When there is a problem in the network, it is hard to pin-poin= t the reason as the operator only has a partial view of the network”. This is of course one example of a technical issue = (another related one is my next comment below). Thus I think that it would = be correct to change this sentence to state:

 <= /p>

    There = still are many, economical and technical, open questions related to

    the de= ployment of such infrastructure.

 <= /p>

 <= /p>

This might have been lost= in the vigorous discussion of other issues which occurred during the first= WGLC, however, my comments from the previous WGLC included one point which has not been addressed. This comment was:

 <= /p>

> Finally, perhaps I m= issed it but I didn’t see any discussion of the

> volume of overhead r= elated to OAM traffic used for liveness detection

> (the need for ITR= 217;s to determine the reachability of ETR’s).

 <= /p>

I still think that we nee= d discussion of the overhead related to OAM traffic. If this is not known, = it might be appropriate simply to add to the second paragraph of section 1 something along the lines of:

 <= /p>

    The ov= erhead related to OAM traffic (for example, for liveness detection) is not = known.

 <= /p>

    &= nbsp;          

Also, in section 3, first= bullet after the first paragraph, the document currently states:

 <= /p>

   o  EID-= to-RLOC mappings follow the same prefix size as the current

    &= nbsp; BGP routing infrastructure;

 <= /p>

In email in our earlier d= iscussion Florin Coras stated:

 <= /p>

> The goal our experim= ents was to understand the

> performance of LISP = map-caches if edge

> networks already own= ing their address space (PI address owners) were to

> switch to LISP. Spec= ulating if and how PA owning edge networks are to

> switch to LISP was o= utside the scope.

 <= /p>

I think that these two po= ints are saying the same thing. However, I am not sure whether most (or all= ) readers will understand that the bullet point in the current document implies the point that Florin made in his email. We could clarify= this in the next paragraph as follows:

 <= /p>

OLD

   The above as= sumptions are inline with [RFC7215] and current LISP

   deployments,= however, such situation may change in the long term.

   Nevertheless= , [KIF13] and [CDLC] explore different EDI prefix space

   sizes, still= showing results that are consitent and equivalent to the=

   above assump= tions.

 <= /p>

NEW

   The above as= sumptions are in line with [RFC7215] and current LISP

   deployments,= however, such situation may change in the long term.

   For exa= mple, the first bullet above assumes that only edge networks

   already owni= ng their address space (current PI address owners) will

   switch to LI= SP. Speculating whether and how PA owning edge networks

   might s= witch to LISP was outside the scope. Nevertheless, [KIF13] and

   [CDLC] = explore different EDI prefix space

   sizes, still= showing results that are consistent and equivalent to the

   above assump= tions.

 <= /p>

Thanks, Ross

 <= /p>

 <= /p>

From: lisp [ma= ilto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone
Sent: Thursday, May 14, 2015 3:44 PM
To: LISP mailing list list
Cc: Joel Halpern Direct
Subject: [lisp] WG Last Call draft-ietf-lisp-impact-02

 

Hi All,

 

the authors of the LISP Impact document  [https://tool= s.ietf.org/id/draft-ietf-lisp-impact-02.txt]

submitted a new version of the draft and requested t= he Work Group Last Call.

 

This email starts a WG Last Call, to end May 28th, 2= 015.

 

Please review this updated WG document and let the W= G know if you agree that it is ready for handing to the AD.

If you have objections, please state your reasons wh= y, and explain what it would take to address your concerns.

 

Thanks


Luigi & Joel

 

 

--_000_BY1PR0501MB14309BCF3B5608CF53D75DC7A5CB0BY1PR0501MB1430_-- From nobody Fri May 29 05:34:01 2015 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 5BE7A1A884E for ; Fri, 29 May 2015 05:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 tHGG6PouU7Dl for ; Fri, 29 May 2015 05:33:57 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D381A884C for ; Fri, 29 May 2015 05:33:57 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so61485385wgb.3 for ; Fri, 29 May 2015 05:33:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:cc:to; bh=p6B+voJ9DVVOKSdssfv7HF5Cd7X2Aq9ZYAEX+V4Wgxs=; b=Tr0X1XRyAtLqtVuwa//PbRwDHh9KfRxq80PMEFLnAbUrvHZoRAyp6fCacJz7swGP08 rNtNPvKmT+AGwBWIuz3IPn/tEtPWB5ck6sySPWwXF7UQ7LyA3eqP8YcCadlXgdjClUTZ 7GiRzqOut9BeAAcmPXzmiSFm5b2XeBA8Oz0iRXCKN6Mpa6LjDETuORqajYd4v5ei3Pvy Z7ifqD8NIZCelrSwjuNCZk8Vpf5xLnALDs5MxxhC6xPlUUef5NZTjKs9ZfP2Lp+Axkyu ZsLGTiLvFvgwy+AqN8oNjTdMptWTEpli1E1PlY8iS+dhA70aZVTHu+z60i49/phYQep4 8gIQ== X-Gm-Message-State: ALoCoQnfMgmSFYraCKdmlOaxKrAytE6IcmsaH+2XQmvQpWOo4B3N3ehR3chZ2n9bNN7nFKaz2fIx X-Received: by 10.180.75.8 with SMTP id y8mr6048288wiv.31.1432902835712; Fri, 29 May 2015 05:33:55 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:2cbb:a06:ecab:df1e? ([2001:660:330f:a4:2cbb:a06:ecab:df1e]) by mx.google.com with ESMTPSA id lj2sm8150371wjb.38.2015.05.29.05.33.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 May 2015 05:33:54 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_299A5E23-921F-440E-B463-B1F763C55916" Message-Id: <1F6A3E9B-62E7-4B5D-99F3-2DE6AC0FB13F@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Fri, 29 May 2015 14:33:58 +0200 References: <96CCC975-4D04-46F4-ABA9-D5BF6A77C451@gigix.net> To: Ross Callon X-Mailer: Apple Mail (2.2098) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-02 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, 29 May 2015 12:34:00 -0000 --Apple-Mail=_299A5E23-921F-440E-B463-B1F763C55916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ross, thanks for your review. I think that your comments can be easily accommodate. Have a look inline. ciao L. > On 27 May 2015, at 23:46, Ross Callon > wrote: >=20 > The document seems much improved. I still have three issues which = should be corrected before the document is ready for publication. > =20 > =20 > Section 1, last paragraph, second sentence. This currently reads: > =20 > There still are many, economical rather than technical, open = questions related to > the deployment of such infrastructure. > =20 > However, it is clear that there are both economical and technical = issues. As examples of technical issues, later in the document (section = 5.2) talks about the difficulty in troubleshooting, and states =E2=80=9C=E2= =80=A6the major issue that years of LISP experimentation have shown is = the difficulty of troubleshooting. When there is a problem in the = network, it is hard to pin-point the reason as the operator only has a = partial view of the network=E2=80=9D. This is of course one example of a = technical issue (another related one is my next comment below). Thus I = think that it would be correct to change this sentence to state: > =20 > There still are many, economical and technical, open questions = related to > the deployment of such infrastructure. > =20 The purpose of the draft is to document what we know about the impact on = the existing Internet. The right thing to do is to delete at once that sentence, because it = does not document any impact.=20 > =20 > This might have been lost in the vigorous discussion of other issues = which occurred during the first WGLC, however, my comments from the = previous WGLC included one point which has not been addressed. This = comment was:=20 > =20 > > Finally, perhaps I missed it but I didn=E2=80=99t see any discussion = of the > > volume of overhead related to OAM traffic used for liveness = detection > > (the need for ITR=E2=80=99s to determine the reachability of = ETR=E2=80=99s). > =20 > I still think that we need discussion of the overhead related to OAM = traffic. If this is not known, it might be appropriate simply to add to = the second paragraph of section 1 something along the lines of: > =20 > The overhead related to OAM traffic (for example, for liveness = detection) is not known. > =20 Rather it would go in section 5.2 as a separate item. > =20 > Also, in section 3, first bullet after the first paragraph, the = document currently states: > =20 > o EID-to-RLOC mappings follow the same prefix size as the current > BGP routing infrastructure; > =20 > In email in our earlier discussion Florin Coras stated: > =20 > > The goal our experiments was to understand the > > performance of LISP map-caches if edge > > networks already owning their address space (PI address owners) were = to > > switch to LISP. Speculating if and how PA owning edge networks are = to > > switch to LISP was outside the scope. > =20 > I think that these two points are saying the same thing. However, I am = not sure whether most (or all) readers will understand that the bullet = point in the current document implies the point that Florin made in his = email. We could clarify this in the next paragraph as follows: > =20 > OLD > The above assumptions are inline with [RFC7215] and current LISP > deployments, however, such situation may change in the long term. > Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space > sizes, still showing results that are consitent and equivalent to = the > above assumptions. > =20 > NEW > The above assumptions are in line with [RFC7215] and current LISP > deployments, however, such situation may change in the long term. > For example, the first bullet above assumes that only edge networks > already owning their address space (current PI address owners) will > switch to LISP. Speculating whether and how PA owning edge networks > might switch to LISP was outside the scope. Nevertheless, [KIF13] = and > [CDLC] explore different EDI prefix space > sizes, still showing results that are consistent and equivalent to = the > above assumptions. What if instead it is explicated in the first bullet: EID-to-RLOC mappings follow the same prefix size as the current BGP routing infrastructure (using a PI model); > =20 > Thanks, Ross > =20 > =20 > From: lisp [mailto:lisp-bounces@ietf.org = ] On Behalf Of Luigi Iannone > Sent: Thursday, May 14, 2015 3:44 PM > To: LISP mailing list list > Cc: Joel Halpern Direct > Subject: [lisp] WG Last Call draft-ietf-lisp-impact-02 > =20 > Hi All, > =20 > the authors of the LISP Impact document = [https://tools.ietf.org/id/draft-ietf-lisp-impact-02.txt = ] > submitted a new version of the draft and requested the Work Group Last = Call. > =20 > This email starts a WG Last Call, to end May 28th, 2015. > =20 > Please review this updated WG document and let the WG know if you = agree that it is ready for handing to the AD. > If you have objections, please state your reasons why, and explain = what it would take to address your concerns. > =20 > Thanks >=20 > Luigi & Joel --Apple-Mail=_299A5E23-921F-440E-B463-B1F763C55916 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Ross,

thanks for your review.

I think that your comments can be = easily accommodate.
Have a look inline.

ciao

L.



On 27 May 2015, at 23:46, Ross Callon <rcallon@juniper.net>= wrote:

The document seems = much improved. I still have three issues which should be corrected = before the document is ready for publication.
 
 
Section 1, last paragraph, second sentence. = This currently reads:
 
    There still are many, economical rather than = technical, open questions related to
    the deployment of such = infrastructure.
 
However, it is clear that there are both economical and = technical issues. As examples of technical issues, later in the document = (section 5.2) talks about the difficulty in troubleshooting, and states = =E2=80=9C=E2=80=A6the major issue that years of LISP experimentation = have shown is the difficulty of troubleshooting.  When there is a = problem in the network, it is hard to pin-point the reason as the = operator only has a partial view of the network=E2=80=9D. This is of = course one example of a technical issue (another related one is my next = comment below). Thus I think that it would be correct to change this = sentence to state:
 
    There still are many, economical and technical, = open questions related to
    the deployment of such = infrastructure.
 
<= font color=3D"#5856d6" class=3D"">
The purpose of = the draft is to document what we know about the impact on the existing = Internet.
The right thing to do is to delete at once that = sentence, because it does not document any impact. 


 
This might have been lost in the vigorous = discussion of other issues which occurred during the first WGLC, = however, my comments from the previous WGLC included one point which has = not been addressed. This comment was: 
 
> Finally, perhaps I missed it but I = didn=E2=80=99t see any discussion of the
> volume of overhead related to OAM = traffic used for liveness detection
> (the need for ITR=E2=80=99s to = determine the reachability of ETR=E2=80=99s).
 
I still think that we need discussion of = the overhead related to OAM traffic. If this is not known, it might be = appropriate simply to add to the second paragraph of section 1 something = along the lines of:
 
    The overhead related to OAM traffic (for = example, for liveness detection) is not known.
 
<= font color=3D"#5856d6" class=3D"">
Rather it would = go in section 5.2 as a separate item.

              =  
Also, in = section 3, first bullet after the first paragraph, the document = currently states:
 
   o  EID-to-RLOC mappings follow the same = prefix size as the current
      BGP routing infrastructure;
 
In email in our earlier discussion Florin = Coras stated:
 
> = The goal our experiments was to understand the
> performance of LISP map-caches if = edge
> = networks already owning their address space (PI address owners) were = to
> = switch to LISP. Speculating if and how PA owning edge networks are = to
> = switch to LISP was outside the scope.
 
I think that these two points are saying = the same thing. However, I am not sure whether most (or all) readers = will understand that the bullet point in the current document implies = the point that Florin made in his email. We could clarify this in the = next paragraph as follows:
 
OLD
   The above assumptions are inline with [RFC7215] = and current LISP
   deployments, however, such situation may change = in the long term.
   Nevertheless, [KIF13] and [CDLC] explore = different EDI prefix space
   sizes, still showing results that are consitent = and equivalent to the
   above assumptions.
 
NEW
   The above assumptions are in = line with [RFC7215] and current LISP
   deployments, however, such = situation may change in the long term.
   For example, the first bullet = above assumes that only edge networks
   already owning their address = space (current PI address owners) will
   switch to LISP. Speculating = whether and how PA owning edge networks
   might switch to LISP was = outside the scope. Nevertheless, [KIF13] and
   [CDLC] explore different EDI = prefix space
   sizes, still showing results that are consistent = and equivalent to the
   above = assumptions.

What if instead it is = explicated in the first bullet:

 EID-to-RLOC mappings follow the = same prefix size as the current
      BGP = routing infrastructure (using a PI model);







 
Thanks, Ross
 
 
From: lisp [mailto:lisp-bounces@ietf.org] On = Behalf Of Luigi Iannone
Sent: Thursday, May 14, 2015 3:44 PM
To: LISP mailing list = list
Cc: Joel Halpern = Direct
Subject: [lisp] WG Last Call draft-ietf-lisp-impact-02
 
Hi All,
 
the authors of the LISP Impact document =  [https://tools.ietf.org/id/draft-ietf-lisp-impact-02.txt]
submitted a new version of = the draft and requested the Work Group Last Call.
 
This email starts a WG Last Call, to end May 28th, = 2015.
 
Please review this updated WG document and = let the WG know if you agree that it is ready for handing to the = AD.
If you have objections, please state = your reasons why, and explain what it would take to address your = concerns.
 
Thanks

Luigi & = Joel

= --Apple-Mail=_299A5E23-921F-440E-B463-B1F763C55916--