Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 23 October 2013 19:27 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7C211E8204 for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 12:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level:
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1ArrVEiJi-d for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 12:27:37 -0700 (PDT)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3711E81CA for <v6ops@ietf.org>; Wed, 23 Oct 2013 12:27:37 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id uo15so1432271pbc.9 for <v6ops@ietf.org>; Wed, 23 Oct 2013 12:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l1/gRNpkCPIrzkWr9lMDRguvDAJQe0Pdzm3oE/F0yJI=; b=u2eDzfbqfOn4i5K/kyTSZQdlh1Jm3Mt+JPYn6BEq/gTu9r38vWmY5R1dYAf5zNbVq6 Yvx7VqcEyqQt7P1YUgqb1swKqtdpfPhKw59gKexWpsL7FYuwoKrJWdQiDnqbHM0w1I/j lAdsFPITjH6NRHkWU2iaALuKgvlI2UfWhUGOjaNw71jv4udUR5TXX46akNfBCrpeT4XM aHX7fKC585OKaVzqTAnWKEo7lGMjMt55IO/FosonO1XcOcSJ2m/M5CyDSJK4ec8lhV+u a55ROGP4Um5I0EWH0dAbUA74bqLVhDH+Z1qNnycQkelsJI4/ZFtw/z1KDTI4A1jJ+Fll 2wEw==
X-Received: by 10.69.4.100 with SMTP id cd4mr3243070pbd.120.1382556457423; Wed, 23 Oct 2013 12:27:37 -0700 (PDT)
Received: from [192.168.178.20] (186.201.69.111.dynamic.snap.net.nz. [111.69.201.186]) by mx.google.com with ESMTPSA id ik1sm6297317pbc.9.2013.10.23.12.27.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 12:27:36 -0700 (PDT)
Message-ID: <5268232A.2000805@gmail.com>
Date: Thu, 24 Oct 2013 08:27:38 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Brian Haberman <brian@innovationslab.net>
References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <D62C71FC-306F-4F91-97E2-84D6F64A58A3@istaff.org> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <CAKD1Yr1SpS0e3qDkZyRsiSB-a_oXCi7nWKe2szxW34mJfhJnxw@mail.gmail.com> <5267ED12.4090602@innovationslab.net>
In-Reply-To: <5267ED12.4090602@innovationslab.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 19:27:38 -0000

On 24/10/2013 04:36, Brian Haberman wrote:
> Hi Lorenzo,
> 
> On 10/23/13 11:31 AM, Lorenzo Colitti wrote:
>> On Thu, Oct 24, 2013 at 12:29 AM, Brian Haberman
>> <brian@innovationslab.net>wrote;wrote:
>>
>>> "In order to provide connectivity between the Legacy Internet and LISP
>>> sites, PITRs announcing large aggregates (ideally one single large
>>> aggregate) of the IPv6 EID Block could be deployed."
>>>
>> That sounds very much like a 6to4 relay router, which experience has shown
>> was an unworkable deployment model. Why is this different?
>>
> 
> It's not different.  But, that is the tact the LISP WG is trying to
> take.  Keep in mind that the referenced draft went through IETF Last
> Call and was subsequently sent back to the WG due to the concerns raised
> about routing and potentially creating a parallel address registry
> outside of the RIRs.

I think there is one difference from the 6to4 case - well, two actually.

1. A lot of operators learnt the hard way that failing to coordinate
6to4 prefix routing between operators caused very substantial problems.
(And, btw, the 6to4 RFC said that such coordination was needed.)

2. LISP has grown out of the routing community, so the need for
operational coordination is presumably understood in that community.

Nevertheless, the risk of a failure of coordination seems high.
But then, it seemed high for BGP4 itself in 1994.

   Brian