Robin, > > I said what is left to do is 1) make a decision (see text right above > > this line) or 2) blend two mapping database scheme. We don't know yet. > > We need to experiment. > > How would experimentation with your current prototype LISP system > lead to any fresh insights about the fundamental limitations of ALT > or NERD? I don't think any is saying that. My sense is that its more the case that while we work on the theoretical aspects of these system (as this thread is, and that is all goodness), there are things that one can learn by observing a system's behavior. To do that you need implementations (or at least simulations). Suffice it to say that a lot has been learned in the process of trying to make things work (especially in the cases of large dynamic systems that are difficult to characterize in a bottom up fashion). So there's a theory v. practice point here (and I'll leave alone for the moment the whole issue of emergent properties that really can't be studied in a bottom up fastion). > NERD on its own won't work because every ITR in the world would need > the full feed of mapping updates. Notwithstanding Eliot's calculations, this is a concern many of us has voiced. 01: That's why hybrid systems seem so attractive; but then you trade off rate v. state. v. lookup latency. All of these systems seem to occupy a different point on in this space (except for perhaps CONS and ALT, which are architecturally similar in this respect). I'm sure there are other dimensions one can through into this, but for now my sense is that these three dominate. > ALT on its own won't work because the ITR drops or greatly delays > (sending them to the ETR via the ALT network) the initial packets > while it waits for the mapping information. This would make EID > address space suck - so no-one would want to use it. goto 01; (I [again, and others] have been concerned not only about latency [your point] but also about the aggregate traffic load in the ALT core [consider near the "top" of the hierarchy, i.e., data traffic "rate" in the control plane]). > The logic of this seems inexorable: Any global query system would > often be so slow that it wouldn't be acceptable unless every ITR is > able to deliver the initial packets via some other mechanism within > a fraction of a second. If all caching ITRs can do that, then why > bother with a global query server network at all? I don't know if the logic is "inexorable", but your point is well taken. We need to examine the tradeoffs in the 3-space I described above. > I don't think anyone believes ALT or NERD alone could possibly form > an acceptable solution, far less the optimal one. Again, "anyone" is a lot of folks. > So that leaves your other suggestion: blending the two systems > together. This is what I explored - making changes to them starting > from the position of the two systems running alongside each other. So this is an architectural tradeoff in the space I was describing. As Noel is found of saying, TANSTAAFL. > When you have NERD ITRs around the place, there is no need to build > the ALT global query and packet delivery system, because it makes > much more sense to use the nearest NERD ITR as a default mapper and > to have a full database Query Server at the same location - perhaps > in the same device as the NERD ITR. Then there is no need for ALT, > CONS or any other global (expensive, hard to administer, slow and > unreliable) query server system. But then you need to construct the complete map; again, this is just a point in the tradeoff space I described above. It would appear that there are only a finite number of ways to skin a cat... > If you or anyone else disagrees with my sequence of improvements to > LISP, you will be able to argue why a particular stage of my > improvements makes the system worse and/or suggest some better set > of improvements. I have a somewhat different suggestion. I don't see any "solutions convergence" occurring, at least on RRG list. What might be helpful is objective criteria that could be used to pick "more optimal" points in the archtiectural space (here I mean the rate*space*latency space). Give such critera, we could do the evaluation. Without such critera, well, we're speculating. Now, I'm not saying we need a "requirements document" (been there, done that). But we do need something objective that we can use to compare against. Dave
Attachment:
signature.asc
Description: Digital signature