Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 16 November 2012 17:26 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697EC21F858E; Fri, 16 Nov 2012 09:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.253
X-Spam-Level:
X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty1RC+ay3Lw4; Fri, 16 Nov 2012 09:26:57 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 01AFF21F84FF; Fri, 16 Nov 2012 09:26:57 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E734A558350; Fri, 16 Nov 2012 09:26:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AC0EB1C0928; Fri, 16 Nov 2012 09:26:54 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E78291C0751; Fri, 16 Nov 2012 09:26:53 -0800 (PST)
Message-ID: <50A67758.8000001@joelhalpern.com>
Date: Fri, 16 Nov 2012 12:26:48 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <CAKFn1SF4+k5gWip-WBNfbjt-qAafPbTSY8L_EBLA9Pqvbw4=kQ@mail.gmail.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com>
In-Reply-To: <50A66B67.5000609@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, lisp@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Nov 2012 17:26:57 -0000

Why does any operator have a reason to carr any routes other than their 
paying customers?  Because it provides connectivity for their customers.
If we get this block allocaed, then it results in 1 extra routing entry 
in the global routing table to support LISP inter-working.
An entry that some of their customers may use, whether the operator 
carrying it knows that or not.

In fact, it would take significant extra work for the operator to 
somehow block this aggregate.

If LISP fails, this is a small cost to find out.
If LISP succeeds, this results in significant reduction in core tabl 
sizes for everyone.

Yours,
Joel

On 11/16/2012 11:35 AM, Brian E Carpenter wrote:
> Joel,
>
> On 16/11/2012 16:00, Joel M. Halpern wrote:
> ...
>> With regard to interworking and deployment, there are a number of
>> documents that deal with that.  They discuss what the currently
>> understood deployment incentives are, and what paths are currently seen.
>>    (As Noel noted, this is an experiment, and one should expect that the
>> actual path will be different from the expectation.)  Given that
>> interworkng dives are data plane devices, altruism is clearly not a
>> sufficient incentive to get this to scale, and the models do not depend
>> upon that.
>
> My concern with this allocation request was not about scaling
> but about black holes. What are the incentives for operators not
> very interested in LISP to carry the routes that make it work?
> That's the root of many of the problems with 6to4 (and, I think,
> many of the problems of the MBONE, for those with long memories).
>
> Regards
>      Brian
>