[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lisp-interest] RE: [GROW] LISP@GROW
> -----Original Message-----
> From: David Meyer [mailto:dmm@1-4-5.net]
> Sent: Monday, August 04, 2008 3:00 PM
> To: PAPADIMITRIOU Dimitri
> Cc: Darrel Lewis (darlewis); grow@ietf.org;
> lisp-interest@lists.civil-tongue.net
> Subject: 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.
I understand this: EID-to-RLOC resolution is distinct from RLOC
reachability. And the point raised goes exactly in that direction: BGP
ALT must be at least as stable as the underlying BGP otherwise it will
result in lowering the availability of the global system. OTOH, the
underlying BGP would be now subject to TR instability while it is still
the only reachability information forwarding can rely on. Hence, ISPs
need to cope with the resulting operational aspects.
> > 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.
Not exactly. Assume Site 1 and 2 with ITR_1/ITR_2 and ETR_1/ETR_2 resp
(some of the figures presented at the GROW meeting are explicit on this
architecture). ITR_1->ETR_1 is used as primary. Disruption along the
ITR_1->ETR_1 path requires re-resolution to re-route traffic on
ITR_2->ETR_2 path.
For both these aspects: the question is: are these assumptions
operationally acceptable (so as to pass the deployability requirement).
Thanks,
-dimitri.
> Dave
>