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

[Dino Farinacci <[e-mail]>]

Good points Joel. I completely agree. 

Dino

On Nov 16, 2012, at 9:26 AM, "Joel M. Halpern" <[e-mail]> wrote:

> Why does any operator have a reason to carr any routes other than their paying customers?  Because it provides connectivity for their customers.
> If we get this block allocaed, then it results in 1 extra routing entry in the global routing table to support LISP inter-working.
> An entry that some of their customers may use, whether the operator carrying it knows that or not.
> 
> In fact, it would take significant extra work for the operator to somehow block this aggregate.
> 
> If LISP fails, this is a small cost to find out.
> If LISP succeeds, this results in significant reduction in core tabl sizes for everyone.
> 
> Yours,
> Joel
> 
> On 11/16/2012 11:35 AM, Brian E Carpenter wrote:
>> Joel,
>> 
>> On 16/11/2012 16:00, Joel M. Halpern wrote:
>> ...
>>> 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.
>> 
>> My concern with this allocation request was not about scaling
>> but about black holes. What are the incentives for operators not
>> very interested in LISP to carry the routes that make it work?
>> That's the root of many of the problems with 6to4 (and, I think,
>> many of the problems of the MBONE, for those with long memories).
>> 
>> Regards
>>     Brian
>> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp