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.
Hi David and Darrel,
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.
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.
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.
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.
In LISP-ALT, this is a big problem, because it will often take one or
more seconds to get this mapping information, and in the meantime,
the ITR needs to send the traffic packets on the ALT network, where
they act as mapping requests and by which they are routed to the
correct ETR. This is slow due to two reasons at least.
Firstly, the ALT network is on a global scale. The ETRs are the only
query servers and they are physically scattered all over the world.
This makes the ALT network slow and unreliable compared to APT's or
Ivip's use of Full Database Query Servers in the local ISP network
(in APT, these are called "Default Mappers").
Secondly, the ALT network is likely to involve very long paths from
ITR to ETR (the response is typically sent back directly via the
Internet to the ITR), due to the high level of address aggregation in
that network, and due to the fact that the paths up and down the ALT
hierarchy are likely to involve a number of routers which are
geographically widely separated.
LISP-ALT's long path problem again
http://psg.com/lists/rrg/2008/msg01676.html
http://www.antd.nist.gov/~ksriram/strong_aggregation.png
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.
Also, the security issues noted in section 3.3 don't apply to Ivip,
since Ivip ITRs are not probing reachability.
A properly designed reachability testing system for Ivip (which is
quite outside the Ivip system, and so can use any techniques at all)
would be secure against interference from spoofed packets. It would
probe reachability of ETRs - and behind them the reachability of one
or more routers or hosts in the end-user network - from multiple
locations in the Net. Depending on the results of these probes, the
system might issue a mapping change command to cause ITRs all around
the world to tunnel or forward packets to an alternative ITR.
Likewise, the problem you describe (3.3):
Aside from the ability to mislead a poorly implemented probing
mechanism with data spoofing, probing creates a fundamentally
unscalable relationship between site pairs (see Section 3.1).
This leads to both implicit (unscalable) and explicit (vulnerable
to probe floods) Denial of Service vulnerability in the systems
receiving probe requests.
Applies to LISP-ALT, LISP-NERD, APT and TRRP - but not to Ivip, since
there is only one system probing reachability, irrespective of the
number of ITRs which are currently handling data for a particular ETR
or end-user network.
Regards
- Robin
http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
