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

["Joel M. Halpern" <[e-mail]>]

It is a fair question to ask whether the allocation strategy and polices 
need to be spelled out at the time of the reservation.  Possibly we made 
the wrong call on keeping them separate.  Part of the issue is that fo 
current experimentation having the block is more important, but for 
longer term experiments, and for implications on other parties, the 
allocation policies matter more.

With regard to interworking and deployment, there are a number of 
documents that deal with that.  They discuss what the currently 
understood deployment incentives are, and what paths are currently seen. 
   (As Noel noted, this is an experiment, and one should expect that the 
actual path will be different from the expectation.)  Given that 
interworkng dives are data plane devices, altruism is clearly not a 
sufficient incentive to get this to scale, and the models do not depend 
upon that.

Yours,
Joel

On 11/16/2012 6:57 AM, Roger Jørgensen wrote:
> On Tue, Nov 13, 2012 at 3:45 PM, The IESG <[e-mail]> wrote:
>>
>> The IESG has received a request from the Locator/ID Separation Protocol
>> WG (lisp) to consider the following document:
>> - 'LISP EID Block'
>>    <draft-ietf-lisp-eid-block-03.txt> as Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2012-11-27. Exceptionally, comments may be
>> sent to [e-mail] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>
>
> I think LISP is an important factor in the future of Internet and I do
> support the idea of having different IP block for LISP based network.
>
> However, I can not support the publication of this document, it has
> some unclear issues that need good answers first.
>
>
>
> Anyhow, I see two issues that need to be addressed better
>
> 1.) How should the address space be administrated, RIR structure or
> something else closer to 6bone? I support the suggested idea of
> discussing this part with the different RIRs to look more into how
> this are going to work in practice.
> And as Dino said, "No, I am not making any assumptions either way. How
> allocation gets done is subject to more work." the document should
> state this.
>
>
>
>
> 2.) The interaction between none-LISP and LISP Internet. This problem
> has two sub-problems within it
>
> a.) Why is there a need for a special LISP block. This is partly
> answered in section 3.  Rationale and Intent. Is this the entire
> reason?
>
> <start copy'n'paste>
>     With the current specifications, if an ITR is sending to all types of
>     destinations (i.e., non-LISP destinations, LISP destinations not in
>     the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the
>     only way to understand whether or not to encapsulate the traffic is
>     to perform a cache lookup and, in case of cache-miss, send a Map-
>     Request to the mapping system.  In the meanwhile, packets can be
>     dropped.
> <end copy'n'paste>
>
>
>
> b.) 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. Are there
> an assumption that some ISPs will announce the entire LISP space (/16
> are mention) for free ?
> If each and every EID space holder (/32 or similiar) each have to
> connect to Internet and get their address space routed, then it's
> nothing different than regular RIR allocated /32's.
>
>
>
> Address these thing somehow in the document, even just mention that
> it's subject for other document and I'm happy... :-)
>
>
>