Opened 9 years ago

Closed 8 years ago

#39 closed technical (fixed)

On the performance of cache lookup (from D. Papadimitriou's review)

Reported by: luigi@… Owned by:
Priority: major Component: draft-ietf-lisp
Severity: - Keywords:


Section 4.1 point 2 (same remark applies to Section 6) misses an
important aspect how the mapping is performed the first time a new
destination EID is seen at ITR and how subsequent maps are
performed. It seems that a) EID-to-RLOC Cache must be first entirely
scanned for each incoming packet at ITR (not only the first one) and
then if there is no entry i) Data probe i.e. copy the destination EID
value in the destination RLOC field (for LISP 1.5) or ii) originate a
Map Request; otherwise use the corresponding RLOC value in the
retrieved entry as destination RLOC. Needless to say that the delay is
proportional to the number of entries in the cache. Nothing is being
said if the cache is full (which entry should be replaced i.e. the
least frequently used, the least recently used, or the least recently
replaced entry).

Change History (2)

comment:1 Changed 8 years ago by luigi@…

  • Resolution set to fixed
  • Status changed from new to resolved

Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion.

comment:2 Changed 8 years ago by luigi@…

  • Status changed from resolved to closed
Note: See TracTickets for help on using tickets.