Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
Joel Halpern Direct <jmh.direct@joelhalpern.com> Fri, 16 November 2012 21:19 UTC
Return-Path: <jmh.direct@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 5BD5821F8B01; Fri, 16 Nov 2012 13:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 aDH9wqlfuOq2; Fri, 16 Nov 2012 13:19:20 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C0AAD21F8AED; Fri, 16 Nov 2012 13:19:20 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 4BA6B559828; Fri, 16 Nov 2012 13:19:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CDE5D1607E8; Fri, 16 Nov 2012 13:19:18 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.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 mailc2.tigertech.net (Postfix) with ESMTPSA id 96A841607E5; Fri, 16 Nov 2012 13:19:17 -0800 (PST)
Message-ID: <50A6ADD0.3040000@joelhalpern.com>
Date: Fri, 16 Nov 2012 16:19:12 -0500
From: Joel Halpern Direct <jmh.direct@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: Sander Steffann <sander@steffann.nl>
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> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl>
In-Reply-To: <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 18 Nov 2012 08:01:42 -0800
Cc: lisp@ietf.org, ietf@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 21:19:21 -0000
Most of what you describe Sander sounds reasonable, and sounds aligned with what is i the deployment documents. The WG debated the EID allocation extensively. One could argue that there is no need for it, that we could merely request that PI allocations be granted for LISP EID usage individually. The WG felt that if we could get all IPv6 LISP EID allocations from a single block that was not used for anything else, that would simplify avoiding lookups in the mapping system that were inevitably going to fail. Thus the allocations request. Yours, Joel On 11/16/2012 4:12 PM, Sander Steffann wrote: > Hi Joel, > >> 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. > > That still assumes the altruistic routing of the prefix. And I am afraid that if the usage of this block gets a bad reputation that all LISP usage will share that reputation. I really like LISP but I am still not convinced that it's a good idea. If we can find a way to get the EID prefix routed in a reliable way then I would love it! > > I really care about LISP and I am afraid that: people see unreliable routing for EID /16 => assume LISP is unreliable. That is why I am pushing so hard to get this sorted out. > > Hmmm. What about the following strategy: > - Start with the EID prefix being handed out like PI > - Either through the RIRs if they are willing to take the responsibility > - Or from a separate registry > - Some altruistic /16 PITRs might show up in the global BGP table > - A holders of a (assume) /48 from the EID prefix can arrange PITRs for their own space > - And announce it as a separate route in the global BGP table (for now) > - Keep the routing and reliability under their own control > - If the experiment is a success we advise ISPs to: > - Install their own PITRs for the /16 > - Filter out the /48s at their border > > The filtering of the more-specifics once they have their own PITRs will make sure that they use those PITRs and that they will use the most optimal path to the locators as soon as possible. It will also keep their routing table smaller. If enough big transit providers offer /16 PITRs to their customers then the more-specifics might be filtered on a larger scale. > > So, summary: > > The ways to reach a PITR would be > a) Run your own PITR (big networks, LISP users) > b) Use one from your transit(s) (smaller networks that don't have their own) > c) Use an altruistic one as last resort > > As long as (a) and (b) aren't a reality the LISP users who don't want to rely on (c) can run/rent/etc a PITR for their own space. I think the routing community would really appreciate it if all those more-specific routes would be temporary until wide deployment of (a) and (b) make them unnecessary. > > And if this doesn't become a success we have a bunch of /48 prefixes to the separate PITRs in the BGP table. It won't be much, otherwise we would have declared success. So the risk of messing the BGP table up is very limited. And when can tell people: if you are bothered by those more-specifics in your routing table you can always deploy your own PITRs and filter the more-specifics at your border. That might keep everyone happy. > > What do you think? > > Thanks, > Sander >
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Roger Jørgensen
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Bert Wijnen (IETF)
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Luigi Iannone
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Luigi Iannone
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… Bert Wijnen (IETF)
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Paul Vinciguerra
- Re: Last Call: <draft-ietf-lisp-eid-block-03.txt>… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel M. Halpern
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George Michaelson
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian E Carpenter
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Arturo Servin
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Roger Jørgensen
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George, Wes
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel M. Halpern
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian E Carpenter
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Paul Vinciguerra
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Paul Vinciguerra
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel M. Halpern
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Cameron Byrne
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Cameron Byrne
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Joel Halpern Direct
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… heinerhummel
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… SM
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George, Wes
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Robert Elz
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Sander Steffann
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… George, Wes
- RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Noel Chiappa
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Geoff Huston
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Roger Jørgensen
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian E Carpenter
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Robert Elz
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Dino Farinacci
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Brian Haberman
- Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-… Luigi Iannone