Re: [lisp] LISP EID Block Size

Dino Farinacci <> Fri, 01 November 2013 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B378521E821A for <>; Fri, 1 Nov 2013 07:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gRruHN+btMzJ for <>; Fri, 1 Nov 2013 07:38:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::22a]) by (Postfix) with ESMTP id 49CBD21E8383 for <>; Fri, 1 Nov 2013 07:38:46 -0700 (PDT)
Received: by with SMTP id z6so1902110yhz.1 for <>; Fri, 01 Nov 2013 07:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OHdYEW00Jsa+0nyCspv9m6kLYQawZuQtO85r9HpPl+Y=; b=LdbhNxLK7jvYdAGmX6eXv3c9uL2NRHnz7S8raEQ10oo8nXWWoNHkFK+FspL8FgzV4L KJWZZlLc9DobLWIB+EyJPEfcYS4inOx7XoANGIN+Osnk9F47AOP4+KBPzXVbtETiQpyz pPr9Ajbm9LciiO0Sgp9FkWT7j5Lcsup1g4Atev9bhtikRoo3d53EiYaPX6HZYDA3ss3X NkfMuKdqSUj76iJK3q33d86CcEnj4meSTE3aJv7Q7CTc32c3uIYCIKda7Io8VrBLCmXL Hp11h4Xly4wSGqkg5mEVgSFy+Ei9hjYMjFUXepT7zN1/77PI3obG7pEEKfPiz5wFbDFq O4Dw==
X-Received: by with SMTP id x32mr2489895yhh.59.1383316725661; Fri, 01 Nov 2013 07:38:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h66sm4882225yhb.7.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 07:38:45 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 1 Nov 2013 07:33:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: "Joel M. Halpern" <>
X-Mailer: Apple Mail (2.1816)
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 14:38:51 -0000

> I understand the importance of experimenting.  But I am having trouble getting my head around the possible value we want to explore.  Color me naive and stubborn, but individually so.
> Thinking about the ITR code path, if there is no block:

Many are thinking in this context. It is one but there are other things WE COULD DO if we new a prefix was an EID. See below for some rough examples. And please don't ask for detail, because this is initial thinking.

> Receive packet
> check cache for destination
> failing cache match, query for destination.

And there could be a failed match if the destination address was not an EID. Meaning this packet is coming to an ITR destined for a non-LISP site (regardless if the source address is an EID or not). So the ITR would have to query the mapping database.

So let's break this down. If the source was an EID, one could say, "okay since I'm doing the new stuff the delay for a lookup to a non-LISP destination is the price I pay for getting multihoming for packets that come back to me". If the source was not an EID, then the old user that expects to go to a non-LISP site expects the packet loss or optimal routing path to continue. And if it does not, then the new service hurt existing users.

Please note, this is when a site is bifurcated being a site that has some partial EID allocations and partial hosts that have not changed. And that either could send to EID or non-EID destinations.

Yes, you could have a default PETR configured in the ITR so there is 0 packet loss, but then you may get a suboptimal path. And packets from a non-EID source to a non-EID destination could be inadvertently encapsulated to the PETR. Then the PETR would decap and deliver the packet based on a BGP path.

I for one, would like to solve this problem. And I do not know if just a well-known, hard-coded, EID-block will do it.

> And the ITR code path if there is a block:
> Receive packet
> check cache for destiantion
> failing cache match, check for destination in EID block
> If in EID block, query
> If not in EID block, query

You are correct, but this box could be configured in way where the logic could change:

Receive packet
If EID-block strict configured
    If destination in EID-block, send query
    Else forward natively
    <do what Joel said above with no EID-block check>

> Now, if everything is in the EID block, I understand that the last step above becomes "just send".  But that appears to be a counter-factual assumption.
> Yours,
> Joel

Having an EID block could help us in these scenarios as well:

(1) The block or any more specifics should not have a native-forward action in a Map-Reply returned by the mapping system.
(2) The block or any more specifics should not be injected into BGP without a special community indicating that only PITRs should be advertising it.
(3) If a destination that a NAT box receives has a source in this block, that translation should not be done (because it is not needed).
(4) If the source is in this block we know we cannot build RPF trees in the core when the source sends multicast packets.
(5) Maybe a special EID-block should indicate that this source host can only talk IPv6 and that stretched layer-2 subnets are prohibited. So if you hit a box that does VXLAN and LISP, that layer 3 LISP is used and we don't move MAC frames across the underly and we certainly do not forward ARP packet, broadcast frames, and link-local multicast.

Now all these things can be put in the mapping database, and give us the same answers but if we could keep load off the mapping database, this would be a good thing, a scalability feature.


> On 10/31/13 7:19 PM, Dino Farinacci wrote:
>>> Actually, that use case is only helped by the EID block if you can
>>> be sure that ALL the destination EIDs it will see will come from
>>> the block.
>> I don't believe so. It could just an efficiency play for one versus
>> the other.
>>> Which seems to be impossible to ensure in the general case.  And
>>> easy to achieve without an allocated block in many of the special
>>> cases.
>> Well the EID could mean it is behind a NAT and that ITRs should
>> encapsulate to an RTR. Maybe one that is used by a default map-cache
>> entry or a distinguished key on the mapping database.
>> See there are sorts of things we could try. Again, "try" here means
>> experimentation.
>> Look how the pilot network was easier to debug since we had
>> generically donated by Andrew Partan and how cisco has
>> been renting 2610:d0::/32.
>> Dino
> _______________________________________________
> lisp mailing list