Subject: [lisp] #39: On the performance of cache lookup (from D. Papadimitriou's review)

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 20 Apr 2010 08:03:15 -0000

#39: On the performance of cache lookup (from D. Papadimitriou's review)
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
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).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/39>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues