Subject: Re: [lisp] LISP EID Block Size

From: [email-masked] (Noel Chiappa)
Date: Thu, 31 Oct 2013 11:18:30 -0400 (EDT)

> From: Geoff Huston <[email-masked]>

    > On 31 Oct 2013, at 2:44 am, Noel Chiappa <[email-masked]> =
    > wrote:

    >> _if_ LISP becomes a huge sucess

In retrospect, I wasn't sufficiently precise here (sorry about that): I should
have said 'if this particular use case of LISP', not just 'LISP', because
obviously this particular concept might not catch on, even while LISP in the
larger sense might.

    > BGP is a huge success - it appears to route 100% of the address space.

I had a bit of a hard time understanding your message, because LISP doesn't
really "route" (in the sense of 'make a path selection') anything.

(OK, in the multi-homing use case, the ITR has to pick an ETR, and there's a
_limited_ amount of path selection going on in that particular use case, but
in general LISP isn't picking paths.)

So I'm going to assume you meant "route" in a more general meaning, i.e.
"handle".

    > If LISP becomes a huge success then why wouldn't it route 100% of the
    > address space, just as BGP does today?

As Dino pointed out, LISP is now more than ready to handle 100% of the IPvN
address spaces - in fact, if you'd read the DDT spec, you'd have seen that
it's going to be handling much more than that, since the 'Extended EID'
includes an 'instance identifier' to allow DDT/LISP to handle multiple
parallel IPvN address spaces (for VPN's, etc).

    > And if it withers and dies then any dedicated address allocation will
    > be too much at that point in time.

This sounds like 'we should never allocate address space to any experiment
because the experiment might fail'. You're not _really_ saying that, are you?

    > If this is all about an _experiment_ under some form of experimental
    > constraint then what are the bounds of the experiment?

I'm not very familiar with this experiment - you'll have to get more details
from the people proposing it.

What I can tell you (which may be helpful in understanding it) is that it
basically involves experimenting with EIDs that are 'facially' (to borrow a
'term of art' from the legal field) EIDs.

At the moment, the only way to tell if an IPvN address is an EID is to run it
through the mapping system, and see if a mapping is available for it. If so,
it's an EID; if not, it's not.

This obviously _could_ take a fair amount of real time (in the units in which
we measure today): an ITR has to talk to an MR, which has to talk to DDT
nodes, etc, etc; if some of these entities are on the other side of the world,
propogation delay alone will be considerable.

With this experiment, you'd be able to tell instantly (a couple of CPU
cycles), just by looking at one of these IPv6 addresses, that it's an EID.
This may, or may not, be useful. The experiment is a way to find out.

    > Why would there be a continuing need to corral LISP into its own
    > dedicated corner of the address space?

I think the answer to this should be clear by now, but if not: LISP as a whole
is not. It's prepared to handle any/all of either IPvN address space.

    > Is there something about scaling LISP to a full unicast routing scale
    > that simply does not work?

Not that I know of; it's designed to handle a full address space (actually,
multiple address spaces, as I mentioned).

    > Or is corralling of LISP into a dedicated block of addresses
    > unnecessary?

It's only the experiment with 'facial' EIDs that has to be corralled into a
block.

    > Why do I feel that this experiment has not been well thought through?

I am astonished that you seem to feel you can make that determination when you
apparently (from your questions here) don't really understand what the
experiment is about?

In a broader way, though, you seem to be implying that an experiment which
"has not been [fully] thought through" is a bad idea. Again, I can't really
believe you're saying that - because I assure you IPv4 wasn't fully "thought
through" when we started on it - but it clearly was a very worth-while
experiment to do.

Mind, I'm not saying this experiment is likely destined for the same level of
success. I myself am unsure that it will reveal any significant benefits
(given that we'll have to support non-facial EIDs 'well' if the overall system
is to be a success), but hey, it seems to me to be worth investigating. (The
initial requested allocation is, after all, ~.0015% of the IPv6 address
space.) Maybe they'll turn up some really nifty use-case for it.

	Noel

---

From: Sander Steffann <[email-masked]>
Date: Thu, 31 Oct 2013 16:41:51 +0100

Hi,

> apparently (from your questions here) don't really understand what the

I think this boils down to a bit from The Zen of Python:

"""
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
"""

If it is difficult to explain what the experiment is about then I understand that people are afraid it might be a bad idea.

Cheers,
Sander

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 31 Oct 2013 11:57:09 -0400

> If it is difficult to explain what the experiment is about then I understand that people are afraid it might be a bad idea.

I'll explain one experiment and will be crystal ear about it. 

(1) We want to have a LISP site send to both LISP sites and not LISP sites. 

(2) We want an ITR to do mapping database lookups when the destination address is an EID. 

(3) We want the ITR to forward packet s by doing a traditional FIB lookup when the destination is not an EID. 

Good Zen?

Dino

---

From: Sander Steffann <[email-masked]>
Date: Thu, 31 Oct 2013 17:31:10 +0100

> (3) We want the ITR to forward packet s by doing a traditional FIB lookup when the destination is not an EID. 

I understand what the technical idea is. There are already EIDs out there (including my own network) that are not in any special prefix. Therefore "address is in special prefix" != "address is an EID". Unless you break LISP for already existing sites I don't see how having a special prefix is going to help in (correctly) determining whether an address is an EID.

> Good Zen?

Sorry, still not (yet?) liking this idea.
Sander

---

From: Rene Bartsch <[email-masked]>
Date: Thu, 31 Oct 2013 17:48:12 +0100

Am 2013-10-31 17:31, schrieb Sander Steffann:
>> (3) We want the ITR to forward packet s by doing a traditional FIB 
>> lookup when the destination is not an EID.
> 
> I understand what the technical idea is. There are already EIDs out
> there (including my own network) that are not in any special prefix.
> Therefore "address is in special prefix" != "address is an EID".
> Unless you break LISP for already existing sites I don't see how
> having a special prefix is going to help in (correctly) determining
> whether an address is an EID.

Consider every consumer gets a random PI-prefix out of the global 
unicast address space. Now you have two problems with a public PITR:

1. What prefixes does the public PITR have to announce? Where to get the 
list from? Scan all Map servers?
2. Billions of random PI-prefixes need millions or even billions of 
BGP-routes to be announced by the public PITR via BGP.

If there's one dedicated EID address space a public PITR only has to 
announce ONE BGP-route to himself.

Best regards,

Renne

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 31 Oct 2013 13:13:51 -0400

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

Yours,
Joel

On 10/31/13 11:57 AM, Dino Farinacci wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 31 Oct 2013 19:19:07 -0400

> 
> 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 153.16.0.0/16 generically donated by Andrew Partan and how cisco has been renting 2610:d0::/32. 

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 01 Nov 2013 02:52:22 -0400

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:
Receive packet
check cache for destination
failing cache match, query for destination.

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

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

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.
>
>> 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.
>
> Look how the pilot network was easier to debug since we had
> 153.16.0.0/16 generically donated by Andrew Partan and how cisco has
> been renting 2610:d0::/32.
>
> Dino
>