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

Sander Steffann <sander@steffann.nl> Thu, 15 November 2012 20:04 UTC

Return-Path: <sander@steffann.nl>
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 CAC3921F842B; Thu, 15 Nov 2012 12:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 2LXJ3PfSGdmd; Thu, 15 Nov 2012 12:04:01 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4B21F841D; Thu, 15 Nov 2012 12:04:01 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 70EA42012; Thu, 15 Nov 2012 21:04:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgHVGRECm+CO; Thu, 15 Nov 2012 21:03:59 +0100 (CET)
Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id A603B200C; Thu, 15 Nov 2012 21:03:59 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
From: Sander Steffann <sander@steffann.nl>
In-Reply-To: <D1AD4093-C3F7-4A35-8108-3E16639E5991@gmail.com>
Date: Thu, 15 Nov 2012 21:03:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB29213E-5381-4FCE-82ED-ABB9E473C83E@steffann.nl>
References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <CAKFn1SFy2+hXJLVtEpkdXfNuXA31ybmYnBFFPXj-73kb3tD+yw@mail.gmail.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <B8132154-7260-43B4-B10D-E5B95924A15D@gmail.com> <50A538B8.7080709@lacnic.net> <D1AD4093-C3F7-4A35-8108-3E16639E5991@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: Apple Mail (2.1499)
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: Thu, 15 Nov 2012 20:04:01 -0000

Hi Dino,

>> 	But who are the registries? The RIRs? Large ISPs? IANA? I think you
>> should specify clearly either: what a registry is or that is not defined
>> yet.
> 
> Yes, nothing has to change in terms of who and how PI addresses are allocated.

Sorry, but if the RIRs are going to allocate from this space then that is not the IETFs decision to make. That responsibility lies with the policy-making community in the RIR's region. And in the RIPE region there is ongoing work to write a policy that removes the distinction between PA and PI for IPv6. So don't make any assumptions here.

Also: if they are handed out as PI addresses there is still the question of who is going to run the PxTRs for that space. No operator will route the whole /12 or /16 for free. Besides the cost, that would put us back to the 6to4 mess: being dependent on (possibly unknown) 3rd-party relays that you have no business relationship with. Assigning the addresses as PI would mean that every block has to be routed separately, which will fill up the routing table. PA would make aggregation possible but tie the end-user to one LISP-ISP, and that ISP might then just use their existing PA block anyway (without using up an extra BGP routing table slot).

I think it should be clear who is going to manage the address space before requesting it.
Sander