Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

From: [email-masked] (Noel Chiappa)
Date: Fri, 16 Nov 2012 09:00:21 -0500 (EST)

> From: <[email-masked]>

    > the routing integration between none-LISP and LISP internet, how are
    > that going to work? The current document isn't clear enough on that as
    > I see it.

The way the routing will work would take a couple of PhD theses to fully
cover (I know of one that's already underway). So it's not really a topic
that can be covered in this ID.

Adding to the complexity is that if LISP becomes widely deployed, how the
routing works will likely change over time; in the early stages, when there
are small islands of LISP, it'll be one thing; later on, when there are
islands of legacy stuff, it'll be totally different. Etc, etc.

    > Address these thing somehow in the document, even just mention that
    > it's subject for other document and I'm happy... :-)

The IETF used to have this concept of 'rough consensus and _running code_';
i.e. we tried stuff out to see if it works. When did we change into an
organization that had to have every 'i' dotted, and every 't' crossed, before
we could move an inch? (Saying 'just refer to the document where it is
covered' doesn't help, if the other document isn't written yet.)

All this ID is trying to do is allocate a rather modest chunk (~ one quarter
of one tenth of one percent - .025% - if I've done the math right) of address
space for an experiment; exactly how it will be best used, and what the best
allocation process is, is to some degree part of that experiment.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 17 Nov 2012 12:12:38 -0500 (EST)

> From: Cameron Byrne <[email-masked]>

    >> If LISP succeeds, this results in significant reduction in core table
    >> sizes for everyone.

    > Not everyone. Only people who carry core tables.

'this results in significant reduction in core table sizes for everyone who
has core tables' sounds a bit tautological, no?

    > That is LISP twist, it transfers cost from a few cores to many edges.

If you define 'many' is 'people who are actually trying to communicate with a
given site', yes. So it has transferred costs for communicating with site X
from 'everyone with a core table, everywhere in the entire network' to 'just
the people who are actually trying to communicate with site X'. This is
bad... how?

(When I first quickly read your message, I thought you were making a point
about the routing overhead of EIDs being carried in the global routing tables
for use by legacy sites, which is an interesting point, but not the one that
you make here.)

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 21 Nov 2012 15:42:55 -0500 (EST)

> From: "George, Wes" <[email-masked]>

    >> Allocation != reservation.

    > You're hairsplitting on semantics in a way that is mostly unhelpful to
    > the discussion at hand.

I _thought_ that the point of the messages from Geoff and others (who were
questioning about how there were no details in the document of how the
allocation would work) was about _how_ the space was to be handed out - to
which the allocation/reservation distinction _is_ important.

	Noel