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

[[e-mail] (Noel Chiappa)]

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

I don't have any comment, one way or another, on what seems to be the basic
point of your note (about what role, if any, the IETF should play in
allocation).

However, there was one aspect I wanted to comment on (it's not clear, reading
your note, if this was clear in your minds):

    > It is noted that the LISP experiment already makes use of a /32 prefix
    > ...
    > If the LISP experiment fills this /32 prefix to such a level of
    > utilisation
    > ...
    > What are the plans to migrate out of the experimental address
    > allocation? Would this renumbering out of an experimental address
    > allocation even be feasible to contemplate if the experiment achieves a
    > level of deployment that is commensurate with the allocation of /16?

The concept, as I understand it, is that there will be no migration "out of
[that] allocation", for the simple reason that the entire rationale of this
range of namespace is that it will be processed differently, i.e. require
special casing in the code in various places; something like:

	if ((dest & EIDSPACEMASK) == EIDSPACEALLOCATION)
		process_one_way();
	  else
		process_another_way();

That being the case, the last thing one would want is either i) changing the
block that is handled specially, or ii) having a number of smaller blocks,
allocated over time, as either one would require much more complex code to
handle: you'd have to have some sort of config file, which could hold
multiple blocks, code to read it, the code to process packets (above) would
have to be able to handle multiple blocks, yadda-yadda.

(Changing the block is the same as having multiple blocks, because past a
certain point you're too big for a flag day, which would be the only way to
avoid having multiple blocks in use at the same time.)

It's that that's driving the suggested reservation, and the smaller actual
allocation: the code would handle any address inside the _reservation_ with
the special processing, but the bulk of the space would be left
_unallocated_, for future allocation in some yet-to-be-determined process
(one which would presumably be set up by the existing namespace allocation
entities), while a small chunk would be allocated to the experiment, for now.


I suspect (I haven't communicated with them directly) that the people who are
involved with this scheme don't really care _who_ allocates the space, and how
- all they care about is that it's all in one chunk - for the reason laid out
above.

	Noel