It is hard to get consensus on anything longer than a sentence, but for the sake of discussion, I think the following would be a good thing for us to agree on.
Here are revised versions of Paragraphs A, B and C from "3 potential consensus questions": http://psg.com/lists/rrg/2008/msg01574.html The original versions did not state time-frames for completing the three threads of research. Paragraph AA is more tentative about an IPv6 solution. My notes in [brackets] are explanatory, not part of what I suggest we agree to. AA: We need to devise a solution for IPv6, or at least recommend directions for future research, unless we expect IPv6 adoption not to grow fast enough for there to be significant scaling problems to warrant a solution. [So I think we would only decide not to work towards an IPv6 solution if one of the following were true: 1 - We fix the IPv4 solution and expect that fix, and IPv4 in general, to last long enough for a clean-slate architecture to be developed and widely adopted. Until then, we expect IPv4 to be usable enough to result in low enough levels of IPv6 adoption for any IPv6 scaling problems to be mild enough not to warrant a solution. 2 - We do not fix IPv4 or IPv6. We expect to be able to develop a clean-slate solution and have most end-users happily adopt it in a sufficiently short period of time that the costs of the IPv4 scaling problem - and any IPv6 scaling problem which results from partial or mass-adoption of IPv6 - will be sufficiently low as not to warrant an IPv4 or IPv6 solution. I think any "IPv6 solution" should be some kind of addition to it - such as map-encap or perhaps Six/One Router - with minimal or no changes to host stacks, applications and the IPv6 BGP system. There has been suggestion of IPv6 with major changes to the addressing and routing structure, and therefore to host stacks and applications, such as (IPv6 + GSE). I regard something like this to be as about as radical (hard to develop, deploy and have widely adopted) as any clean-slate design - so maybe we would be better with a really clean slate.] BB: We need to pursue a solution for IPv4, since we will probably decide we need one. Alternatively, we expect the IETF and/or the rest of the world will insist there be one, and it would be best if we suggested such a solution. Reasons for this include that IPv4 is the Internet in current use - and that it is the only Internet with a routing scaling problem. Also, we cannot be confident most end-users will want to adopt a scalable IPv6 or a clean-slate solution in sufficient time that the costs of the IPv4 routing scaling problem will remain acceptable. CC: There are three worthy avenues of investigation which we should pursue in parallel, with differing levels of urgency: 1 - A solution which is optimal for IPv4 and which may be applicable to IPv6, but which may not be optimal for IPv6. For an IPv4 solution to be widely adopted, no host changes can be contemplated, except perhaps minor changes to help alleviate (necessarily minor) performance difficulties (not reachability or reliability limitations) inherent in the solution. [e.g.. host changes which make it more acceptable for TRRP's and LISP-ALT's delay of initial packets.] We should aim to specify this solution for IPv4 in 2009-03, since it needs to be developed to the RFC stage by about 2011 or 2012, deployed soon after, and ideally be widely adopted by 2014 or so. [Of the current proposals, only the map-encap proposals might be feasible for IPv4.] 2 - An IPv6 solution which may be one of: a - Conceptually compatible with the IPv4 solution, but potentially different in detail. [This means the same map-encap system as adopted for IPv4.] b - Fundamentally different from the IPv4 solution but, like the IPv4 solution, involves no host changes or at most minor changes. [Of the current proposals, only Six/One Router with multiple parallel PA prefixes for each PI prefix meets this criteria.] c - A radical revamp of IPv6 which involves major changes to host stacks and applications. [GSE has been mentioned, but not properly proposed. I regard any such revamp as being about as difficult to get adopted as as a truly clean-slate proposal.] Since an IPv6 solution is not as urgent as an IPv4 solution and since we may not be able to research this field so well, or agree so much about it, our recommendation for this may be more tentative, concerning several options for future research. The nature and urgency of the IPv6 solution would depend in part on: How soon we think the IPv4 solution could be widely adopted. How the IPv4 address depletion problem develops - which will depend to some degree [opinions vary widely] on how an IPv4 solution [presumably map-encap] could enable more end-user networks to get the space they need, without significantly worsening the routing scaling problem and in ways which enable better utilization of IPv4 address space. How soon a clean-slate proposal could be deployed and how rapidly we think end-users would migrate to it. 3 - A clean slate solution, unconstrained by the current state of IPv4 or IPv6. There is no way the RRG could reliably decide on the nature of this solution in the next 9 months. We should recommend some lines of research and suggest some requirements and goals for the new architecture, including those concerning transition mechanisms from IPv4/6 and/or backwards compatibility with them. As this architecture is to last forever, we should also consider how it may support goals beyond the challenges of the current scaling problem, such as how the architecture supports security (including spam reduction), mobility and global QoS. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
