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

From: [email-masked] (Noel Chiappa)
Date: Wed, 21 Nov 2012 08:48:51 -0500 (EST)

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

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

---

From: "George, Wes" <[email-masked]>
Date: Wed, 21 Nov 2012 09:58:01 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Noel Chiappa
> Sent: Wednesday, November 21, 2012 8:49 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP
> EID Block) to Informational RFC
>
> 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:
>
> 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
> 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.)
>
[WEG] Then the draft needs to say some variant of the above - why it can't migrate, why a flag day won't work, and why it needs that size block right now for an experimental technology, including some justification about the size of the block. If the allocation justification is not going to be done within the RIR community, then it needs to be done here. Noel, you specifically complained about IETF not allowing experiments to proceed while some details are still a little hand-wavey [1], but you seem to want it both ways. If this is to be permanent space, then permanent justification and level of detail is required. If it's to be an experiment, then it should expect that there will be at least one renumber as it transitions from experiment to production. I don't think that expecting code to handle two blocks (the experimental one and the permanent one) is asking too much, nor is it expecting too much to require a line in the sand to ensure that the transition between experiment and production happens before "you're too big for a flag day".
If a single permanent allocation that never changes is truly necessary, putting a sunset date on the allocation from IANA seems a reasonable solution to me, but no one really responded to that in my last mail [2]. If the experiment is wildly successful and leads to a permanent deployment, then the currently experimental RFCs get updates written to elevate them to proposed standard, and while we're at it, we remove the sunset date from the IANA allocation. If the experiment ends up being a science project and doesn't gain wide deployment, this reclaims the space to prevent it from being another "Class E" space that is essentially stranded by an allocation that is no longer used.
>
> 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.
>
[WEG] and the people who are involved in number allocation have clearly told "the people involved in this scheme" that they do care who allocates the space and how, especially if the experiment has no bounded end. I think a compromise is doable, but saying "it's not important right now" probably isn't going to make the problem go away.

Thanks,
Wes George

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg75920.html
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg75919.html

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.