From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Noel Chiappa
Sent: Wednesday, November 21, 2012 8:49 AM
To: ietf(_at_)ietf(_dot_)org; lisp(_at_)ietf(_dot_)org
Cc: jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu;
jcurran(_at_)arin(_dot_)net; pwilson(_at_)apnic(_dot_)net;
iesg(_at_)ietf(_dot_)org
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:
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.)
[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 experime!
nt 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.