[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Some comments on draft-farinacci-lisp-06
- To: dino@cisco.com
- Subject: [RRG] Some comments on draft-farinacci-lisp-06
- From: Roland Bless <bless@tm.uka.de>
- Date: Fri, 04 Apr 2008 14:03:51 +0200
- Cc: rrg <rrg@psg.com>
- Organization: Institute of Telematics, University of Karlsruhe
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
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...)
* 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?
* 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.
* 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.
* 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?
Regards,
Roland
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg