Overlapping Map prefixes in EID map cache

[hartmans-ietf@…]

Sam, Margaret, and Noel have claimed that handling of overlapping map prefixes is unclear in the spec. In the resulting discussion it became obvious that first the WG needs to discuss to what extent overlapping prefixes should be supported. Noel said:

we should _first_ decide it we want to _allow_ overlapping mappings, or
just outlaw them. Only if we decide to keep them would we need to go
through and make them work right (which involves a number of things,
not just the 'don't discard longer entries').

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

[luigi@…]

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

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 ?

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

[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

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?

[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

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 ?

[luigi@…]

Replying to luigi@…:

This is Comment 23 of Rekhter's review.

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.

[luigi@…]

Replying to luigi@…:

This is Comment 24 of Rekhter's review

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

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?

[luigi@…]

Replying to luigi@…:

This is Comment 24 of Rekhter's review:

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

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 ?