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 protected]> 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
