On Tue, Apr 08, 2008 at 05:19:40PM +0200, Roland Bless wrote: > Hi Dave, > > thanks for your fast response, comments inline...
Any time...
> David Meyer wrote:
> >> * 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.
>
> My point was just that a reader doesn't know these details when
> reading the terminology section.
Ok, gotcha. We'll fix in the next version
>
> > 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).
>
> Yep.
>
> > 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
>
> Ok, good, probably this point should be emphasized in the next draft
> version.
Noted.
>
> > 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.
>
> Fine.
>
> >> * 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)?
>
> Probably not. What I meant was:
> If a single end-system sends packets to all different EID prefixes
> (e.g., as some kind of random probing mechanism...), then the
> ITR is presumably in trouble if the cache cannot hold all the different
> EID prefixes and their mappings, because it may have to preempt a large
> portion of already cached entries. The effect will get worse if you have
> several such end-systems behaving like this. This behavior may, however,
> be not malicious but legitimate.
> So is there any idea about the cache size? Would it be at the current
> size of a FIB or much smaller?
Understand. We think the cache will be much smaller (due
EID aggregation, among other effects). There are a few
studies on this exact topic underway was we speak. I'll
see if I can get my hands on those tech reports (the only
issue is that I'm not sure if they are finished yet).
Dave
signature.asc
Description: Digital signature
