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 21:48 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 B3C4A21F8A40; Thu, 15 Nov 2012 13:48:51 -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 oRNAywDRicEE; Thu, 15 Nov 2012 13:48:51 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id E620321F8A3E; Thu, 15 Nov 2012 13:48:50 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 479FB2012; Thu, 15 Nov 2012 22:48:50 +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 3Vuyvuo7-wcr; Thu, 15 Nov 2012 22:48:45 +0100 (CET)
Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 53248200C; Thu, 15 Nov 2012 22:48:43 +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: <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com>
Date: Thu, 15 Nov 2012 22:48:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D40BD502-1E3A-4AAA-A040-E2E4EE83141D@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> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <D470B9D8-977F-4E8B-8EDF-7769D5773279@gmail.com> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@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 21:48:51 -0000

Hi,

>>> 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".

Ok :-)

But I think it comes down to
  COULD ignore that certain EIDs are in the mapping system and always route them legacy-style

I wouldn't agree with
  COULD know if certain addresses are EIDs or not by looking at the prefix
because any address space can be used as EIDs now. Or are you proposing to deprecate the use of all other address space as EIDs?

>> 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.

ROFL. No sorry, that's not going to work
a) they would have to pay all the bandwidth cost for users of that EID space that they have no business relation with
b) as a user of that EID space I would be at the mercy of PITR operators that I don't even know
c) See all the arguments about why 6to4 is unreliable. They'll apply here too

>>>> 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.

What makes you think that all those PITRs will pay the cost for routing all that traffic?

>> 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. ;-)

No, sorry. I now pay my ISP to make sure my connectivity works. In your example I'm going to rely on some unknown PETR for outbound traffic and on whatever PITR is closest to the other side for my inbound traffic. I might be able to control the PETR, but not the PITR because that depends on the routing from the other side. We have been here before with 2002::/16. Don't repeat that huge mistake!

- Sander