Subject: Re: [lisp] Last call for draft-ietf-lisp-12

From: Ronald Bonica <[email-masked]>
Date: Thu, 19 May 2011 18:59:36 -0400

Folks,

Please excuse the long-winded question that follows.

In Section 6.1.5, you deal with the issue of overlapping EID prefixes. Specifically, you say:

   "When an ETR is configured with overlapping EID-prefixes, a Map-
   Request with an EID that longest matches any EID-prefix MUST be
   returned in a single Map-Reply message.  For instance, if an ETR had
   database mapping entries for EID-prefixes:

     10.0.0.0/8
     10.1.0.0/16
     10.1.1.0/24
     10.1.2.0/24

   A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
   count of 1 to be returned with a mapping record EID-prefix of
   10.1.1.0/24.

   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.

   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 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."

>From this text, I abstract the following rule:

"When a map-cache contains a less specific EID-prefix, it must also contain all more specific, subsidiary EID-prefixes. Otherwise suboptimal routing will result."

But this leads me to the following questions:

1) What happens when all of the subsidiary EID-prefixes are not configured on the same ETR?

2) What happens when the ITR truly needs the less specific EID-prefix, but there are hundreds of subsidiary, more specific EID prefixes? Will this cause cache churn? Even if a few subnets are so configured?

3) You say above, "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." First, why would the ITR ever query for the more specific. It already has the less specific and has no reason to believe that a more specific exists. Second, what happens if the new, more specific has a very short TTL? Would you want it to time out before the less specific?

4) Assume that a more specific and a less specific will time out at the same second, which is far in the future. If one of them needs to be bumped out of the cache (due to churn), MUST it be the less specific? (I assume so, but I can't find this in the spec.)

                                                     Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 19 May 2011 19:15:26 -0400

Folks,

How does LISP deal with EID-map cache churn in general. For example, assume that a device behind an ITR is infected with a variant of SLAMMER. However, instead of probing port 1434 on IP addresses 0.0.0.0 through 255.255.255.255 in that order, this variant probes IP addresses in random order.

If several hosts behind the ITR were infected, would cache-churn adversely impact the ITR? The MAP server? Would the impact of control plane saturation be felt before the impact of bandwidth saturation?

                                                       Ron