On 2009-01-03 19:54, Robin Whittle wrote: > Short version: We should reject Strategy B.
For the record, I disagree, for reasons given earlier. However, that doesn't mean we shouldn't recommend that a strategy A approach be brought to fruition. There's no reason why this group is limited to a binary choice. <snip> > > Most of the Strategy A proposals (LISP-NERD, LISP-ALT, APT, Ivip > and TRRP) are intended to work with IPv4. > > Strategy B proposals cannot help with the IPv4 routing scaling > problem because there is not enough space for each multihomed > end-user network to be given a prefix by each of its two or more > ISPs. Correct. And is it unthinkable that the fix for IPv4 (which is running out of addresses) should be different from the architecture for IPv6 (which isn't)? On the contrary, it would be very strange if the solution was the same. <snip> > Strategy B: There are no properly documented proposals. > > ILNP may be a Strategy B approach but it is not > properly documented as a scalable routing solution. > There is no Summary and Analysis in the RRG wiki. It's unclear to me that ILNP belongs in B since it has characteristics of A as well. Whether it's jumped through the hoops of the wiki strikes me as uninteresting; it seems to be well documented. > > HIP has been mentioned, but no-one seems to be > proposing it as a scalable routing solution. I think Pekka observed that this wasn't even a goal. (My quick answer is that it only becomes a routing solution if it solves the same mapping problem that strategy A generates.) Shim6 has also been mentioned, as a mitigation of some the issues with the multiprefix PA model. That is already chartered IETF work with full documentation. > Every possible Strategy B approach would be vastly harder to have > adopted by the majority of end-user networks which want multihoming, > TE and portability (or its functional equivalent) than any Strategy A > approach, for at least two reasons: > > 1 - Strategy B solutions require most or all current Internet users > to adopt IPv6 - and furthermore IPv6 with a modified host > stack, API and applications. The first half of this is increasingly likely to happen anyway. It isn't certain that the API and apps have to be touched; rolling out new stacks over five to ten years really isn't a valid objection. But I fully agree: strategy B == IPv6. > > 2 - Strategy B solutions provides benefits to adoptors only when > the other host in a session (stack and relevant applications) > has been upgraded too. So until almost all networks and their > hosts adopted it, the scheme could only provide multihoming for > a fraction of communication sessions. This is true. The question is whether this (piecemeal incentives, highly distributed low costs) is really less effective than the incentives to pay the highly concentrated per-network costs of strategy A. > > Also, I argue that any approach which involves pushing > responsibilities and management traffic to all hosts (all potential > Strategy B approaches) is fundamentally flawed: > > http://www.irtf.org/pipermail/rrg/2008-November/000233.html Highly distributed = scaleable. And in any cases, hosts have always been responsible for traffic management (that's called TCP) and approaches like SCTP and the proposed multipath TCP extend that. So I don't think we should condemn this in the abstract. > > > I find it impossible to imagine how a Strategy B solution could > succeed if we fail to solve the problem via the best one or more > Strategy A solutions being properly developed and offered for adoption. > > RRG rejection of Strategy B solutions is not to suggest that people > shouldn't work on such schemes. Just that we have no confidence that > any such scheme could turn out to be technically better and/or easier > to have widely adopted than a well developed version of the best of > the Strategy A schemes. > > Of course, if the best efforts with Strategy A schemes fails, then > everything would be up for reconsideration. However, that is a > potential scenario in the post-2020 future. Then, any Strategy B > solution would still involve much higher barriers to development and > adoption than any Strategy A solution. Exactly. Which is why my preference is to recommend development work on strategy A and continued R&D on strategy B; I'd be very concerned if we shrugged our shoulders and dropped it for 12 years. Brian _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
