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 [EMAIL PROTECTED] 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
