[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lisp-interest] RE: [GROW] LISP@GROW
> Afaik in LISP, the xTR is addressable by an RLOC (taken from PA space)
> right ? Does that not result in a dependence ?
It can be, but its only the address of the xTRs. So its
not the same as renumbering an enterprise. The latter is
what Vixie termed "CIDR Provider Lock", and it the
"dependence" (as you put it) that folks are concerned
about.
> 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.
Managed CE is a great product for SPs (at least it was
for every SP I worked at). That said (and I'm guessing
here), managed CEs are likely to be a small fraction of
the CE population; Kurtis made this exact point somewhere
earlier in this thread.
> > 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.
i.e, I query the DNS and get a name, but there is no
reachability to the IP address that the name resolves to.
> Not reaching the mapper may also be a problem in case of ongoing traffic
> disruption.
If you're saying "if the mapping system is broken, then
the mapping system is broken", then I agree with that
(independent of which mapping system your talking
about). And The same can be said of the underlying
connectivity, so I don't really understand your point.
Dave