Re: [lisp] 6830bis Review - scalability

Dino Farinacci <farinacci@gmail.com> Wed, 27 December 2017 05:28 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8521241F5 for <lisp@ietfa.amsl.com>; Tue, 26 Dec 2017 21:28:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8Tg7b79qv_V1 for <lisp@ietfa.amsl.com>; Tue, 26 Dec 2017 21:28:32 -0800 (PST)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (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 9FC151201FA for <lisp@ietf.org>; Tue, 26 Dec 2017 21:28:32 -0800 (PST)
Received: by mail-pl0-x22e.google.com with SMTP id b12so18955458plm.3 for <lisp@ietf.org>; Tue, 26 Dec 2017 21:28:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J6aXxrlISIY5u+82CirceJrGRglue6wqk06+EidKrx0=; b=idbg/DmpHffEw2Ell4zGrUrjtdfmyjMajJTSezDU8aFFcQqOfLqUFqR9qt3hQRg7e+ bNwOVfLDOH2IdRqXTDo9nwk/VDWBFjXRGEGIOc2zOP4/4W7tV+oWqf89sm8BZkRTDFV0 lq5ztamZTJG3mr5IzmQG3/fhL9otXwSwlgu8azH6AYveuDsOWSwicL3n9oUILmN6BtWB 38KghUHn81Oj7pMYYq141fSI9XUKEpUILdxMJYx9olK2LfIyk9+kpxQRPue0p763AF3o QzV/ZBv8bPrkO64ukALKeJxHgkf11Io/G4P4fhMp5HJc+JTxJ8pDgtNhXHfYIUvt+PI6 4BSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J6aXxrlISIY5u+82CirceJrGRglue6wqk06+EidKrx0=; b=iN0bsxs9kkqF2GGL1Yz92kUzRAV3JuFF3nYpyMNHXXk/TmRFDf6nhlIeXbcnyVCXu6 phv2tcGU11utwmYwLlOkgTf8mucvylpd/sg5kLwnGhkGxZIbQFSfJDYcCPC7dy+za7wT 0tTEMw9x7bXW8M412U6xhKrdaJmXPA6FKDgVTaqOZ03WRN6YUxjm6Yk5KP5e01EUE31N BW9Q3QO0W0eHbeY8r5RwwS55jTZ01ex8jxLP5FodjuWDLSxLLksrffNFZemfZmxtbyjY eHMQr8sywRprtBWxOebEOWkbKmygjUZC3ceiR25am6MNTgYcKqiB1RP9US591jayAxUi 3Qug==
X-Gm-Message-State: AKGB3mKauRX2f7vRm/16srkS0/kSkpi2Cjnenflg91SHkFY/8eSxDFr7 8PY+k4deRJPBgVfx10Z7eMY=
X-Google-Smtp-Source: ACJfBovj67+5wVfIRWrdfMv1qRaTmCPXaJa9xjSUmHBbPeidYerUbku0qpUkff9DB2IrgDT7FubDQQ==
X-Received: by 10.84.133.67 with SMTP id 61mr27729451plf.20.1514352512151; Tue, 26 Dec 2017 21:28:32 -0800 (PST)
Received: from ?IPv6:2603:3024:151c:55f0:1ca2:28e8:b31:5b77? ([2603:3024:151c:55f0:1ca2:28e8:b31:5b77]) by smtp.gmail.com with ESMTPSA id u81sm67402363pfa.70.2017.12.26.21.28.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Dec 2017 21:28:30 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <e0ff44b2-a315-3b02-9268-cbd8165fac78@joelhalpern.com>
Date: Tue, 26 Dec 2017 21:28:29 -0800
Cc: Albert Cabellos <albert.cabellos@gmail.com>, "lisp@ietf.org list" <lisp@ietf.org>, lisp-chairs@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <27C29B7E-D491-4D98-88DF-69E6C7BA8FC7@gmail.com>
References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <CAGE_QexqW=q51kXR9fo_8YDu6VVUHCBz-XrGt5iZ6FOTRxDLiA@mail.gmail.com> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> <e0ff44b2-a315-3b02-9268-cbd8165fac78@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/9I61nRzFdZeGy0rQ67HHZ-0WGl0>
Subject: Re: [lisp] 6830bis Review - scalability
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Dec 2017 05:28:34 -0000

> Clearly, scalability of LISP matters.
> However, we are explicitly not attempting to move LISP to standards track for purposes of solving global Internet address scaling problems. The agreement under which we are doing this is to focus on the value of the other uses of LISP.

Right, that is not the sole problem to solve. But removing the features of what overlays bring to the document would not be a good idea.

> To put it simply Dino, if we try to make the argument that LISP is suitable for Internet-scale 

That is not what the text is saying. The text that people are commenting on is that the aggregatabeility of RLOC addresses should be present in the document.

> deployment, and for solving the core growth difficulties, we will have a large set of additional arguments to undertake.  If we focus on what we have agreed, we get Proposed Standards without having that fight.  And we get to use a PS for all sorts of interesting and desirable tasks.

I agree that the document should not say we are trying to scale the Internet. And I believe it does not say that.

Dino

> 
> Yours,
> Joel
> 
> On 12/26/17 11:13 PM, Dino Farinacci wrote:
>> I will comment here before providing a new update and response to Luigi’s latest email.
>>> On Dec 26, 2017, at 5:48 PM, Albert Cabellos <albert.cabellos@gmail.com> wrote:
>>> 
>>> Hi
>>> 
>>> Thanks for the review, please find my comments inline.
>>> 
>>> I have removed all the comments for which I **agree**:
>>> 
>>>> 
>>>>   Provider-Assigned (PA) Addresses:   PA addresses are an address block
>>>>      assigned to a site by each service provider to which a site
>>>>      connects.  Typically, each block is a sub-block of a service
>>>>      provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
>>>>      is aggregated into the larger block before being advertised into
>>>>      the global Internet.  Traditionally, IP multihoming has been
>>>>      implemented by each multihomed site acquiring its own globally
>>>>      visible prefix.  LISP uses only topologically assigned and
>>>>      aggregatable address blocks for RLOCs, eliminating this
>>>>      demonstrably non-scalable practice.
>>>> 
>>>> Last sentence to be deleted is a relic of scalability discussion.
>>>> 
>>>> 
>>> 
>>> Agreed. I suggest deleting entirely the definitions for both PA and PI, they are not used throughout the document.
>> Note, we still care about scalability of any underlay, especially the Internet core, so we should leave this in. Note, we ARE still solving the scalability problem.
>> I don’t know why any of you would think differently.