Hey Robin, > Short version: The problems mentioned in draft-meyer-loc-id- > implications apply to LISP-ALT and to some > extent LISP-NERD, APT and TRRP. > > None of these problems exist with Ivip. >
Well, stating that is one thing, demonstrating it at a
sufficent level of detail is another. I'd welcome the
latter.
> Regarding your I-D:
>
> Architectural Implications of Locator/ID Separation
> http://tools.ietf.org/html/draft-meyer-loc-id-implications-00
>
> I think the two problems you raise:
>
> Locator Path Liveness Problem
> State Synchronization Problem
>
> are problems for LISP-ALT. I think the first is a problem for
> LISP-NERD, but not the second.
Well, NERD does have this problem. It just pays the
(pre-sync) price at some central site. That has its own
set of problems, but they all derive from the same basic
issue. The difference is basically one of "pay me now or
pay me later" (or as many folks on this list are fond of
saying, TANSTAAFL).
> I think the first is a problem for APT and TRRP, since in these
> schemes - as in LISP - the ITR is given multiple LOC addresses for
> any one EID prefix, and achieves multihoming service restoration by
> testing reachability to these LOCs and choosing which one to use for
> traffic.
>
> The Locator Path Liveness Problem does not exist with Ivip. A system
> external to Ivip is used to probe reachability of the ETRs, and this
> system will typically automatically change the mapping in real-time
> to achieve whatever multihoming service restoration goals the
> end-user network administrator desires. The probing, decision making
> and mapping change system is likely to be distributed over multiple
> geographically dispersed servers all over the Net, and to be operated
> by a company which specialises in such services. Each end-user
> network will be able to choose between multiple such companies and
> have their chosen company probe the reachability of their network in
> any manner they desire.
"A system external"..."is likely". Really?
Please explain. There's not enough information in what
you said to understand what you are proposing. But
briefly, the "system external" to Ivip (whatever that may
be) is needed precisely because Ivip (and every other
Loc/ID split architecture I've seen) has the reachibility
problem.
I'll note here that host based solutions (e.g., HIP,
SHIM6) also have the locator liveness problem, but in
general don't have the state sync problem.
> Since Ivip's mapping changes in real-time in response to multihoming
> outages, or as a means of dynamically achieving inbound traffic
> engineering, the mapping information consists of a single ETR
> address. So ITRs are not involved in reachability testing and have
> no decisions to make between multiple ETR addresses for multihoming
> or for TE.
So you put reachability information in the mapping
database?
> The State Synchronization Problem does in principle exist in Ivip.
> If there are two caching ITRs and one of them is currently getting
> all the traffic, its cache will be fresh and fully matched to the
> traffic. If, for some reason - such as a change in the internal
> routing system - a second ITR suddenly receives all this traffic, the
> second ITR won't have the mapping already cached for the various
> micronets (EIDs in LISP terminology) of the destination addresses of
> that traffic.
Well, you state the problem does not exist and go on to
describe the problems that we've already described. What
would be useful/interesting is for you to provide a
detailed description of what you are proposing as a
solution to either or both of these problems, and how
they avoids, say the trivial failure secnaros described
in the draft.
> With Ivip, or with APT, there is very little problem due to delays,
> since the second caching ITR will request mapping information for all
> the micronets (EIDs) it needs and get the responses very quickly
> (milliseconds) and reliably, from one of the Full Database Query
> Servers in the same ISP (or end-user) network. With APT, the
> response comes from one of the Default Mappers in the same ISP.
Have you noticed that the default mapper is in the data
path? It (the default mapper) is also in the site's
IGP. That may be ok, but you're talking about a big piece
forwarding engine to handle this. In addition it (the
default mapper) needs to be on-path during failures to be
able to re-route to another ETR. Now information is split
between the ITR (which during the failure has old
information) and the default mapper.
BTW, note that the default mapper also also needs to get
mappings from outside the site, so the fact that it's in
the same ISP isn't really relevant (sure, you can push
all the mappings (equivalent to hosts.txt) to the default
mapper (that's the NERD case), but that doesn't help when
things are changing (of course, there's a state latency
tradeoff here).
> Also, the security issues noted in section 3.3 don't apply to Ivip,
> since Ivip ITRs are not probing reachability.
Agin, you state that, but you don't state how. The devil
here is the details.
Based on your comments, it seems to me that you didn't
understand that the purpose of the draft was to more
deeply understand the architectural implications of
Loc/ID split, not to advocate for or against any
particular proposal.
Dave
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
