Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06: question c - discarding more specific prefixes

From: Alia Atlas <[email-masked]>
Date: Fri, 24 Jun 2011 02:22:10 -0400

Vince, Dino & Joel,

On Thu, Jun 23, 2011 at 5:46 PM, Vince Fuller <[email-masked]> wrote:
> On Mon, May 16, 2011 at 06:26:53PM -0400, Alia Atlas wrote:

>> c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide
>> that it does not wish to store such more-specific information, it has
>> the option of discarding it as long as a shorter, covering EID-prefix
>> exists."  I found this confusing and it seems to violate the prefix
>> rules in [LISP], as well as they were described.
>
> If a covering map cache entry exists (i.e. 153.16.0.0/16) and the more-
> specific prefixes are discarded (i.e. 153.16.10.0/24), then data traffic
> would be LISP-encapsulated and sent to one of the RLOCs for the covering
> map cache. This is no different than the way a shorter prefix can be used
> for IP forwarding to any more-specifics of that prefix.

It's possible I'm missing something (as always), but I would like to be
persuaded because this sounds like a clear case of the ability to cause
traffic dropping accidentally.

First, the covering map cache entry may send traffic to RLOC A while
a more specific prefix would send the traffic to RLOC B.

The ETR which owns RLOC A has, as required in [LISP] sent the more specific
prefixes - but an ITR, according to the above quoted sentence in Sec 7.2, can
discard them.

As I understand it, if the ITR chooses to do so, then the ITR would
forward packets
in the more specific prefix to RLOC A.

At the same time, in the email thread with Dino on [LISP], I asked:

" For instance, if an ETR receives a LISP encapsulated packet and
decapsulates it, but
 does not have EID locally, what should the ETR do?"

and Dino said "Drop it".

If both his answer and your response on correct, then the ITR, by
dropping a more
specific prefix mapping, is guaranteeing that traffic to that more
specific prefix will be dropped.

I do not believe this meets a reasonable definition of "correct" behavior.

It also contradicts the carefully detailed rules in the base LISP draft.

Can we please clarify the correct behavior so that the appropriate
draft(s) can be updated?

Thanks,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Jun 2011 02:33:31 -0400

I believe Alia is correct about this.

Unless I have missed something, there is no way for an ITR receiving 
nested prefixes to tell the difference between the case (described in 
the base LISP spec) when the longer prefix MUST be used, and cases of 
traffic engineering where it is only a matter of preference.

As such, since the base overlap case requires that longer prefixes be 
retained, this text (in the second paragraph of 7.2) seems to violate 
the base requirements.
If there is some way that an ITR can actually tell the difference 
between the two cases, this text needs to say taht.  I don't think there 
is any such method.

Yours,
Joel

On 6/24/2011 2:22 AM, Alia Atlas wrote:
> Vince, Dino&  Joel,
>
> On Thu, Jun 23, 2011 at 5:46 PM, Vince Fuller<[email-masked]>  wrote: