Re: [lisp] LISP EID Block Size

[[e-mail] (Noel Chiappa)]

    > From: Geoff Huston <[e-mail]>

    > On 31 Oct 2013, at 2:44 am, Noel Chiappa <[e-mail]> =
    > 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