In einer eMail vom 30.07.2009 20:56:22 Westeuropäische Normalzeit schreibt [email protected]:
The architecture v. engineering debate is a red herring that gets thrown around too easily. Every PhD student has to do a literature survey to understand what has been done, in order to demonstrate that there is at least something new to do that will improve society. That is what is needed here. 100 % d'accord. Nothing more, and certainly nothing less, and it has been woefully lacking in the past. N.B., I am not asking that we get stuck in history– that is a favorite pastime of this organization, but there is a balance between the two extremes. If we are going to create a new mobility architecture we should understand how the existing ones work and don't work, and recognize what is worthy of our time and what is not. Yes.Yes. Yes.My two cents: LISP is just to rescue an architecture which has nothing in mind with respect to mobility. I do not blame the existing architecture because it is older than the mobility objectives. But what I do blame is to ignore mobility objectives and to rescue an architecture which is not at all appropriately designed. > We've all done the numbers. What I stated were common pitfalls the conversation usually follows like: - trying to solve the problem exclusively at L3, a favorite within the IETF. You and I know that not considering these problems from the transceiver to the application means poor deployment (more on this later) Yes,yes,yes. IMHO IEEE is completely ignored, i.e. the possibility to cooperate, instead endless discussions are done about MTU-size problems due to additional (LISP) headers. IMHO, the IETF and the IRTF think to hold all marbles in the own hands, but this is a wrong judgement. IEEE is in a much better position because it is handling the layer 2. And is competent and eager to deal with Mobility. Of course, it would need layer 3 advertisements, but there are well-known patterns how to do that (BGP does MPLS label propagation for VPNs, why shouldn't it propagate Mobility-relevant information like geographical coordinates and have the IEEE solve the problems which the IRTF tries to solve for the last half decade) . - not using the right tool for the right purpose. I'll spare the guilty parties, but you know who you are. - simply not understanding what problem they are solving, and what problems to leave for others. How many efforts (and perhaps entire companies) have failed because of scope? The IETF perhaps goes to the other extreme now, but we'll leave that alone - attempting to shoehorn every last problem into a solution. I believe in the need for locator/id separation, but it is not a panacea. I believe in locators which have location significance i.e. by which you get a metric system, and not in location-agnostic RLOC identifiers as provided by LISP. For instance, use of different locators may have involve different costs, that may need to be exposed all the way to the application layer. The iPhone demonstrates this best of all with some of its apps. And so the app can't simply cope with an identifier, as many would like. It has to have additional information (although it may not need the locators themselves). But back to that literature survey thing. People are often quite hard on MIPv6, and often for the wrong reasons. While MIPv6 bind times have often been viewed as atrocious, often ranging from 20-60 seconds, in many instances that has been due to poor signaling in the layers below. The real problems with MIPv6 (putting aside triangular routing in MIP) is the need for v6, firewall impedance mismatch, and poor interaction of the layers above and below L3. There are assuredly other problems I'm not mentioning, like the complexity of dealing with private address spaces. HIP implementations have some of these problems. But that is often times it- we may in fact have the right Internet standards but need work elsewhere. And some of this, such as FW traversal may be just poor incentive alignment, or scope creep, depending on how you view the problem. How do you view the problem? To restate my main point: if we're going to design a new system, we had darn well better understand the old systems, and what their limits are. 100 % d'accord. BTW, what was the outcome of the rrg-meeting with respect to mobility? IMHO it would be a big progress, if people acknowledged that - no matter what has been accomplished by MIBv4 /v6 so far - that neither the IPv4 nor IPv6-routing architecture are designed as to deal with these issues in a natural way. Heiner Eliot _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
