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

Dino Farinacci <farinacci@gmail.com> Thu, 15 November 2012 21:24 UTC

Return-Path: <farinacci@gmail.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 B526121F84C4; Thu, 15 Nov 2012 13:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Level:
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 vOedzSx6UjkA; Thu, 15 Nov 2012 13:24:20 -0800 (PST)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9121F84BA; Thu, 15 Nov 2012 13:24:20 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id fb11so1381767pad.31 for <multiple recipients>; Thu, 15 Nov 2012 13:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kYmcTdpLPsEfAPHYGzr2ANvg1WHU/HT6u+8U4+Pxtzs=; b=uJOqAE475ibKzFyh4LEH+KGy/5ORC7Y+PqythaUmN+ljwjzUhe9NDhsloC/4K7QTlQ uEzGTyZT3NkIpO9j36N/pZTCkPWpN/wwD3IaEGAvp1pv1/0RWVQgmxF9QLEgts3uFaTp mlh5xfQVOdopug3eWRHiO+4qbZsx3VeBn8r2PpfRh1sB6Bn2lmR9XLHm8NyZfSrIZs7/ 1zrRsdoOmD1V3/20x5Iq/sgN2IfWwCXFbRX4kLe2WC0teNMTpb+fqyCrrSwf7Botm8Pn sqbRwzZT+X4NT/FfVgTtSTmkyvLzC3qAGYfnhbHk13oWvc8DTWJKsmkRXc0bht5N3Gxz DyKQ==
Received: by 10.68.248.1 with SMTP id yi1mr2869788pbc.93.1353014659904; Thu, 15 Nov 2012 13:24:19 -0800 (PST)
Received: from dhcp-10-155-59-220.cisco.com (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPS id is6sm10054834pbc.55.2012.11.15.13.24.18 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 13:24:19 -0800 (PST)
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: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl>
Date: Thu, 15 Nov 2012 13:24:18 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D470B9D8-977F-4E8B-8EDF-7769D5773279@gmail.com>
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> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl>
To: Sander Steffann <sander@steffann.nl>
X-Mailer: Apple Mail (2.1499)
X-Mailman-Approved-At: Fri, 16 Nov 2012 08:43:07 -0800
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 21:24:20 -0000

> Hi,
> 
>>> How are you going to allocate space to ISPs?
>> 
>> This is PI space. The registries will take portions of this space to allocate to end devices.
> 
> Are you thinking about the existing RIRs here? If so: it might be a good idea to notify them that this is coming.

Nothing is coming. Nothing really needs to change.

But if there is anything written up to define allocation procedures, the RIRs can review such a document.

The main motivation for this prefix is to optimize ITRs so they know that a destination is in a LISP site. This COULD eliminate a mapping database lookup for a destination not in this range. Meaning, if a packet is destined to a non-EID, you may know this by inspecting the address rather than asking the mapping system.

>> This draft is purely a draft to REQUEST space. There will need to be a deployment guide on how to allocate EIDs, in general.
> 
> And if the RIR system is used every RIR will develop its own policy for allocating EIDs independently (hopefully based on the recommendations in such a deployment guide). It will have to be very clear whose responsibility it is to allocate from this space, and when assigning responsibility it might be a good idea to make sure they accept that responsibility too.

Right.

> Note that I am not opposing the idea. I'm just trying to make sure this address space doesn't disappear into a black hole because nobody takes the responsibility to manage it.
> 
> One thing we have to be very careful with here is that EIDs are not directly allocated/assigned to end sites from this block. That will cause everyone to independently find (different) PITRs for their space,

Why not?

> which will make a mess of the global IPv6 routing table...

And why do you think you need to assign PITRs per sub-block?

Dino

> 
> Thanks,
> Sander
>