[lisp-interest] RE: [GROW] LISP@GROW

["Darrel Lewis (darlewis)" <darlewis@cisco.com>]

> 
> we did not have had sufficient time to discuss during 
> grow@ietf72 the operational issues related to the deployment 
> scenario of LISP. i would have appreciated to discuss the 
> following points together with the operational community:

Hey Dimitri.  I think if there was a common theme in the Dublin
IETF it was 'we didn't have suvvicient time'... :-)

While I don't speak for the community, I can speak for the
intent of the LISP crew, many of which are ex-operators.

> 
> a) CE-based vs PE-based xTR -> LISP makes use of the former 
> what is the operational impact ? is deployability becoming 
> easier vs. operational constraints ?

LISP's preference for CE based xTRs is based upon a few major
factors.  First the we feel that the PE is already
an overloaded box.  Second, and in my mind more important,
a key benefit of loc-id split is provider independence.

Now provider mobility cuts both ways, it reduces de-facto
lock-in for customers who get PA space from their provider. 
But it also allows for sites to add additional provider
connections much easier.  

Allowing for more sites to have additional connections
without stressing the routing system seems to be a win for
everyone.


> 
> b) Can operational community afford a one time renumbering 
> (EID) assumption considered by LISP/is it a realistic 
> assumption ? or is the alternative consisting in reconnecting 
> sites so as to result into a EID contiguity a 
> possible/feasible scenario ?

If a site has PI space today, its not assumed that they will
have to renumber.  However, the current demand for PI space
seems to indicate that PI is a popular concept.  IMHO
PI space, and what that entails, seems to be a compelling 
benefit to weigh against the cost of one time renumbering.


> 
> c) LISP-ALT relies on BGP-based overlay mapping system 
> (EID-to-RLOC) -> as LISP is CE-based isolation from CE 
> instabilities would now impact the mapping system (note: 
> about 80% of the instabilities result from failure events on 
> eBGP links and proportionally such events resulting into BGP 
> instability increases towards the edges).

The answer to this point is that the ALT is highly aggregated, 
and aggregation dampens instability.  Since the ALT is not 
directly responsible for site/link reachability, we can allow
less dynamicity in the system.  The ALT is responsible for
Subscription time mapping events, not failure time reachability.


> this would result 
> into the same convergence time issue than actually 
> experienced by the current BGP RS (note: the number of TR is 
> proportional to the number of customer
> sites) ?


Thanks for the note!

-Darrel