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:36 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 968D621F89C7; Thu, 15 Nov 2012 13:36:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level:
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 G1QevkXJL9Me; Thu, 15 Nov 2012 13:36:43 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4421F89AC; Thu, 15 Nov 2012 13:36:43 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id uo1so1461375pbc.31 for <multiple recipients>; Thu, 15 Nov 2012 13:36:40 -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=kt8KG1sCA0zCl0XqVj8kuWUC/8V/bxmBKXC4N31GIpM=; b=wSb7FY6WQdOBzx0d40kVDCsHzpD3ebvZMEnb/OydWWgxlKQBX5YocxfBjZ/Tgusqvo KAsIIP4nx8sOl4TEZHUGyBahnKJZhE15/KWKxRKdGDfuLnOU8xXohdlKuF7xUvYq79XP Y3fj811poW3hPSTlde4rOtOdp65VIkuIPVFAFCAduHqEi71uK1nE7gNJtK8uvZDKRUQi KfojqFg/pMMdaJbDjeSMyUOxoQ4DhlSDpYWpQ7ooBNjb/D4XMaK7cEhaz4gKSBUW54UM On2rAS/Dp3MFxFD3f/sdX7zPMhPpCp+M1vqW7tfkqpAdqTLH9WT+Tzu1mE9Wy1VfpooL 08/A==
Received: by 10.66.87.34 with SMTP id u2mr6686117paz.82.1353015400161; Thu, 15 Nov 2012 13:36:40 -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 m7sm10307372paz.3.2012.11.15.13.36.39 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 13:36:39 -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: <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl>
Date: Thu, 15 Nov 2012 13:36:38 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2007FD20-0EA4-4204-81A5-D9AE0201419D@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> <D470B9D8-977F-4E8B-8EDF-7769D5773279@gmail.com> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@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:36:44 -0000

> Hi Dino,
> 
>> 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.
> 
> I don't agree. For example: I'm using regular space for LISP EIDs now, so you can't assume that if it's not in this block that it's not in the mapping system...

That is why I capitalized "COULD".

>>>> 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?
> 
> Because the RIR communities will probably just refuse to allocate from this space if it means that all those routes end up in the BGP table... They are already plenty of people that don't like regular PI policies...

You have all the PITRs in the world advertise only the one /12 into underlying routing.

>>> which will make a mess of the global IPv6 routing table...
>> 
>> And why do you think you need to assign PITRs per sub-block?
> 
> I hope that is not necessary, but if addresses are assigned to end-sites directly in a PI-like way then who is going to provide PITR services for the users? Someone has to pay the bandwidth cost for operating 

PITR services are provide for non-LISP sources to send to these sites. If you have a well-known defined /12 that all PITRs advertise, then when you allocate sub-blocks, you don't have to change, reconfigure, or touch the 1000s of PITRs deployed.

> a PITR... And the users of that space want reliability, so they are not going to rely on the goodwill of some unknown 3rd parties. There is too much bad experience with 2002::/16 for that.

We do that all the time on the Internet unless you sent this email on a source-route to me. ;-)

> If you see another way that I am missing please let me know! I want this to work, I just don't see how...
> - Sander

Dino