Re: [lisp] LISP EID Block Size

Rene Bartsch <> Fri, 01 November 2013 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3653611E8301 for <>; Fri, 1 Nov 2013 06:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.032
X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j1+FA0Z+8yFP for <>; Fri, 1 Nov 2013 06:03:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AC0AC21E8390 for <>; Fri, 1 Nov 2013 05:57:46 -0700 (PDT)
Received: from [] ( by with esmtpa (Exim 4.68) (envelope-from <>) id 1VcEIL-0005qp-4o; Fri, 01 Nov 2013 13:57:45 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 01 Nov 2013 13:57:45 +0100
From: Rene Bartsch <>
To: Sander Steffann <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail
X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl
Cc: LISP mailing list list <>
Subject: Re: [lisp] LISP EID Block Size
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Nov 2013 13:03:12 -0000

Am 2013-11-01 13:45, schrieb Sander Steffann:
> Hi,
>> I want to ask everyone on the list: Which facts prevent a scaling 
>> experiment with the aim of global production state? In my opinion a 
>> /16-EID-prefix is perfect for that goal.
> The problem is in that what you describe depends on public PITRs, and
> we have seen how badly that worked for 6to4 public relays. Running a
> public relay costs money (equipment, maintenance, bandwidth), and when
> nobody pays for them then we cannot expect any decent quality. And
> LISP will be blamed and seen as an unreliable protocol, just like
> 6to4. Relying on public relays is a very bad idea.
> Now, if some big tier-1 transit networks start running production
> quality PxTRs (because PxTRs attract traffic, and their customers pay
> for traffic) then I can see some possibilities. If the LISP traffic
> volume increases then other networks might also start running PxTRs so
> they don't have to pay their transits for it, and then we are getting
> somewhere. But as long as 'public PxTR' means 'someone with good
> intentions but no real responsibility' then this will be a dangerous
> experiment for LISP...

That's an important argument.
We shouldn't rule out public PITRs because of the huge traffic to be 
expected, provide a /16 EID-block and hope it will attract operators of 
backbones and internet exchanges. Maybe we can define some Quality of 
Service rules for PITRs to discourage fun installations with low 

Best regards,