Subject: Re: [lisp] #26: Overlapping Map prefixes in EID map cache

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

#26: Overlapping Map prefixes in EID map cache
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |       Owner:                 
    Type:  technical              |      Status:  new            
Priority:  major                  |   Component:  draft-ietf-lisp
Severity:  -                      |    Keywords:                 
----------------------------------+-----------------------------------------

Comment(by luigi@…):

 '''Dimitri Papadimitriou raises a related question in his review of draft-
 ietf-lisp-06.txt:'''

 Nothing is said what happens if a more accurate EID prefix is being
 made available when a less EID prefix is being in use for a set of one
 or more RLOCs.

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

---

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

Comment(by luigi@…):

 Section 6.1.3 does not explain the result of refresh for which the
 received EID block would be larger than the requested one. Section
 6.1.5 assumes that a “that a Map-Reply may contain different
 EID-prefix granularity (prefix + length) than the Map-Request which
 triggers it.” But it doesn’t say if the associated RLOC shall be
 identical or not ?

-- 
Ticket URL: <http://64.170.98.42/wg/lisp/trac/ticket/26#comment:2>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 07:22:18 -0000

Comment(by luigi@…):

 '''Yakov Rekhter raises a related question in his review of draft-ietf-
 lisp-06.txt (part 2):'''

 Section 6.1.5 EID-to-RLOC UDP Map-Reply message

    A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
    count of 3 to be returned with mapping records for EID-prefixes
    10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.

 Why would those three prefixes be returned? A more general comment is
 that what a Map-Reply must return in response to a given Map-Request
 is underspecified (or the specification is not comprehensible). To
 address this perhaps insert something like the following:

 When an ETR replies to a Map-Request, it must reply with its
 EID-prefix that is the best match for the Map-Request. In addition, if
 it is configured with any EID-prefixes which are more-specifics of the
 best match EID-prefix that it returns in its Map-Reply, it must return
 all of those more-specific EID-prefixe s in the same Map-Reply.

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/26#comment:3>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 12:13:25 -0000

Comment(by luigi@…):

 There are several problems with the following paragraph:

  Note that not all overlapping EID-prefixes need to be returned, only
  the more specifics (note in the second example above 10.0.0.0/8 was
  not returned for requesting EID 10.1.5.5) entries for the matching
  EID-prefix of the requesting EID. When more than one EID-prefix is
  returned, all SHOULD use the same Time-to-Live value so they can all
  time out at the same time. When a more specific EID-prefix is received
  later, its Time-to-Live value in the Map-Reply record can be stored
  even when other less specifics exist. When a a less specific
  EID-prefix is received later, its map-cache expiration time should be
  set to the minimum expiration time of any more specific EID-prefix in
  the map-cache.

 First, it assumes that the ITR will exactly obey the TTLs given in the
 Map-Reply. Most caching systems allow caches to manage timeouts on
 their own, especially allowing early timeouts (for example to create
 space in the cache if it fills). If this is NOT allowed in LISP (and
 it seems not to be), that needs to be spelled out. What are the bad
 consequences of timing entries out at different times, which are not
 equal to the TTLs given?

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 12:16:20 -0000

Comment(by luigi@…):

 The following sentence is confusing:

  When a more specific EID-prefix is received later, its Time-to-Live
  value in the Map-Reply record can be stored even when other less
  specifics exist.

 And this sentence:

  When a a less specific EID-prefix is received later, its map-cache
  expiration time should be      set to the minimum expiration time of
  any more specific EID-prefix in the map-cache.

 isn't clear as to what it's mandating. Is this a requirement for ITR
 behavior ?

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 11:48:26 -0000

Comment(by luigi@…):

 Replying to [comment:3 luigi@…]:

 This is Comment 23 of Rekhter's review.

 lisp-06.txt (part 2):'''

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

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Apr 2010 13:53:18 +0200

Hi All,

Yakov asked to clearly add his comments number to the tickets that his review has generated (this may facilitate the tracking from the original review).

I will proceed to the update, which translates in a number of mails from the issue tracker.

Unless you are really interested in the comment number you can safely discard the forthcoming emails, since I will not change the content.

Luigi

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 11:55:07 -0000

Comment(by luigi@…):

 Replying to [comment:4 luigi@…]:

 '''This is Comment 24 of Rekhter's review'''

 lisp-06.txt (part 2):'''

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 11:56:36 -0000

Comment(by luigi@…):

 Replying to [comment:5 luigi@…]:

 '''This is Comment 24 of Rekhter's review:'''

 lisp-06.txt (part 2):'''

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Apr 2010 13:57:21 +0200

Luigi,

Are these all new issues?  Are there overlapping comments?  And can we 
get a summary of all the open issues once you are finished?

Thanks,

Eliot

On 4/22/10 1:53 PM, Luigi Iannone wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Apr 2010 14:49:37 +0200

Hi Eliot

On Apr 22, 2010, at 13:57 , Eliot Lear wrote:

> Luigi,
> 
> Are these all new issues? 

No

> Are there overlapping comments? 

> And can we get a summary of all the open issues once you are finished?
> 

I did not change any issue. What I did is just add the comment number as provided in the original review of Yakov.

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Apr 2010 14:51:43 +0200

Hi All,

(Sorry for the spam.)

all updates are done, so please consider reading mail from the tracker from now on.

Luigi