Subject: Re: [lisp] Discussion of comment 3 (Map-Replies) [was: Re: comments on draft-ietf-lisp-06.txt (part 1)]

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Apr 2010 16:36:44 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    > Do you have detailed solutions to all of the outstanding issues in your
    > list?

I have reviewed the list, and all except one (listed below) have more than
one possible solution listed.

For instance, for "Packets received when the cache has no mapping", I have no
less than four possible remediations listed - plus there's now a new one
since I last updated the list (which is to send the packet to a PITR which is
advertizing the destination).

BTW, that example illustrates something else about the list: many of them are
performance issues, not 'failure' issues - i.e. the design as currently
promulgated works, but it could be faster. The question of course in each
case is whether the extra performance is worth the extra complexity.

    > your claims about ... "can usually be deployed incrementally", and
    > "with no need to co-ordinate the deployment of the fix" are nothing
    > more than a collection of (unsubstantiated) assertions.

I also checked to see if, for each issue (with the exception noted above), at
least one potential solution does not require a protocol change and/or
co-ordinated deployment. With one exception ("Mappings take a while to
arrive" - i.e. at least one RTT) this is also true.

Speeding up the arrival of mappings would require some significant work - but
this is hardly news to anyone, I expect!

The only issue for which I do not have a solution is "EID reachability",
which we are currently discussing here. (Well, I have a 'solution' listed,
but it's not very useful: it says "Ignore it". :-)

That is for the reasons previously discussed here:

    >> Since this limitation seems to already be generally acceptable today,
    >> we did not think it desirable to add the extra complexity/overhead
    >> which would be needed in order to 'solve' a problem that apparently
    >> the world is not clamouring to have solved.

But let me read the rest of your post, on this specific issue, and comment.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Apr 2010 16:48:16 -0400

I think that there is a slight miscommunication.
It is true today that routing can give misinformation, and packets will 
be black-holed for a time.
But whether that is true or false today for our current system, the 
question being asked is:

Do we have a problem with information inconsistency and potential 
block-holes in LISP.
Yakov provided a clean disassembly of the questions.
The LISP document has to answer the questions for LISP.

The answer may be that the semantics are such that there is no problem. 
  If so, we need to clearly describe the semantics, and how they are 
achieved.
rather more likely, the semantics are such that there is are corner 
cases where bad things happen.
We don't have to solve all such corner cases.  We have to document what 
the behavior (and semantics is).  We can then say "This does result in 
the following failures... in the following circumstances ..."  And then 
we can say whether and why that is okay for this experiment.  (That last 
bit might include references to experience with existing systems.  But 
until we have stated the behavior, the existing behavior of the current 
system is not the quesiton.)

yours,
Joel

Noel Chiappa wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>