ietf
[Top] [All Lists]

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

2012-11-16 20:20:15
Good points Joel. I completely agree. 

Dino

On Nov 16, 2012, at 9:26 AM, "Joel M. Halpern" <jmh(_at_)joelhalpern(_dot_)com> 
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
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp

<Prev in Thread] Current Thread [Next in Thread>