> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Noel Chiappa > Sent: Wednesday, November 21, 2012 8:49 AM > To: ietf@xxxxxxxx; lisp@xxxxxxxx > Cc: jnc@xxxxxxxxxxxxxxxxxxx; jcurran@xxxxxxxx; pwilson@xxxxxxxxx; > iesg@xxxxxxxx > 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 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.