Hey Roland,
On Fri, Apr 04, 2008 at 02:03:51PM +0200, Roland Bless wrote:
> Hi Dino,
>
> while reading draft-farinacci-lisp-06 some questions
> came up, so here are my comments as hopefully useful
> feedback:
>
> * Sec 3., p.11: "Data probe" definition: at this
> point it is not clear whether the data probe packet
> is a kind of special packet or whether it's a normal
> packet (one could guess the latter since you don't
> want end-host modifications...)
Right, its not a special packet (in terms of there being a
"Data Probe" packet format). Its just a packet in which
the inner and outer destination are the same, and which
is routed over the LAT to the ETR that is authoritative
for the EID-prefix covering the EID in the destination
address field in the outer header.
The point of routing this packet over the LAT, of course,
is to avoid losing the first packet in a flow (we've had
a massive discussion on the list about packet loss,
delay, etc). BTW, this is a fairly generic problem, and
turns up in a wide variety of places (ARP, multicast
bursty source, etc).
The crucial point to obsever here, however, is that the
Data Probe packet is used only for the *first flow
between sites*, not between individual flows or anything
more granular than the EID-prefix returned to the ITR in
the Map-Reply. In particular, after the first (Data
Probe) packet from site A to site B and after the ITR
(in site A) receives the Map-Reply from the ETR (in site
B), all traffic for this or any other flow between site
A and B flows over the the "native" Internet, and not
over the ALT topology.
That said, you could force the ITR to send a Map-Request
over the LAT rather than sending a Data Probe (we're in
the process of doing some measurement of the effect of
this). You could also pre-populate the ITR's cache this
way if you knew you were going to have popular sites and
wanted to prime the cache, say with google or something
like that. Whether pre-populating your cache in this way
buys you anything is the subject of ongoing experimentation
and analysis. IMO it doesn't seem like pre-population
would be too useful, since as soon as the first person
gets to work (or whatever) and fires up a web browser,
most (or all) of these sites are going to be populated in
the ITR' cache, and everyone else at the site will use
take advantage of the fact that those mappings are
already available.
> * Sec. 4.1, number 3:
> "LISP 1...In either case the packet arrives at the ETR."
> I asked myself at which ETR the packet actually arrives
> in case of multi-homing, esp. how would this work for PI-like
> EID prefixes? If I understood the proposal correctly, in LISP 1
> there are entries in the DFZ tables that map the EID prefix
> to ETR RLOCs. So in LISP 1 there would be not much
> reduction in the DFZ tables for these cases?
First, which ETR a packet arrives at (if there is more
than one) is controlled by the information returned to
the ITR by the mapping system (or by local config). You
are also right that in LISP 1 EIDs need to be routable
"through the RLOC topology for bootstrapping EID-to-RLOC
mappings."
That said, LISP 1, 1.5, 2, 3 were just ways enumerating
the possibilities with respect to EID-to-RLOC mapping
functionality. We're really working on LISP 3 (i.e.,
the case in which EIDs are not routable on the global
Internet, and are used by the ITRs keys to lookup the
EID-to-RLOC mapping in some database). The current focus
is on LISP+ALT.
> * Sec. 4.1, number 5:
> as probably already discussed on the list
> is caching in the ITR basically a problem if
> end-systems send packets to a large number of
> different EIDs. IMHO this is a source for trouble
> or target for DoS attacks as we experienced also
> problems with (route) caching during sending probing
> packets to randomly generated IP addresses (for some kind
> of bootstrapping P2P overlays). So if the
> cache is not something like a complete FIB today,
> I see problems that such communication patterns
> will not work properly with LISP.
Can you be more specific about the problems you are
concerned about? Is there something beyond the standard
DoS case against a cache (distributed scanning attack or
the like)?
> * Sec. 5:
> "it is recommended, in IPv4 that packet do not get
> fragmented..." sure that there is no fragmentation
> by routers in IPv6, but something should be said about
> IPv6 as packets can become too large by tunneling, too.
Noted, thnx.
> * Sec. 6.2.:
> The text refers to "client-side" and "server-side"
> which were not introduced before. Wouldn't it be better
> to speak of source site and destination site?
I see your point. We'll fix it in the next rev.
Thnx,
Dave
signature.asc
Description: Digital signature
