[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lisp-interest] RE: [GROW] LISP@GROW
Lewis,
> -----Original Message-----
> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com]
> Sent: Monday, August 04, 2008 10:51 AM
> To: PAPADIMITRIOU Dimitri; grow@ietf.org
> Cc: lisp-interest@lists.civil-tongue.net
> Subject: RE: [GROW] LISP@GROW
>
>
> >
> > 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'... :-)
Indeed. I hope we can rectify this for the next mtg. Using the mailing
list for now would allow for a broader community to provide for their
opinions.
> 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.
Afaik in LISP, the xTR is addressable by an RLOC (taken from PA space)
right ? Does that not result in a dependence ?
The question is probably which incentive are brought to the client-side
to upgrade their CEs ? or as Lixia mentioned those could be operated by
ISP themselves but is that not going to delay deployment and increase
operational expenses ? It would be interesting to see operators
viewpoint here.
> 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.
Let me add one point raised in addition to my post to Lixia replies: the
BGP-based ALT (used for exchanging EID reachability) and BGP (used for
exchanging RLOC reachability) are not necessarily congruent. The latter
could flap while the former does not or vice versa. The result of this
is that one could reach the mapper but not subsequently the forwarder.
Not reaching the mapper may also be a problem in case of ongoing traffic
disruption.
thanks,
-dimitri.
> > 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
>