Hi Joel, You wrote:
> Robin, your note assumes several agreements which have not yet been > reached. > > We have by no means explored all of the host based or transport based > solutions. The WG has not agreed that the solution must be on a site > level. There are certainly advantages to site level solutions, but it > is not a done deal. Perhaps this would be a good thing to settle soon. The question of which way to branch at the "map-encap / translation / transport" junction depends in part on how acceptable a purely host-based approach would be. I can't see how any scheme which requires host changes could be widely enough adopted to solve the IPv4 routing scaling problem, so I think we can safely discount any part of the solution space which doesn't give the network administrator the tools they need via routers etc. rather than by changing hosts, to isolate their hosts from changes in routing, multihoming service restoration adaptations, moving the network to a new provider etc. > We have not even had any serious discussions about whether IPv6 only > solutions are worth considering. You simply assert that we must have v4 > as well as v6 solutions. I assumed this was agreed, but apparently not. I raise the prospect of IPv6-only solutions in a separate message: "What do we have consensus on?" > Again, there are good reasons to want > solutions for both spaces. But there are also strong arguments in terms > of deployment and actual need that indicate that a v6 only solution may > be more deployable and more useful. I personally wonder if we might > well be better off with a v6-centric solution. I completely disagree. If the RRG and later the IETF comes up with an IPv6 only solution, it won't help at all with the IPv4 situation. I can't see how current IPv4 end-users will be tempted or able to switch to IPv6-only addresses in sufficient numbers in the next decade to alleviate the IPv4 routing scaling problem. > You list several further "must not" that are not yet working group > agreements. Several of them look like good ideas. But it is a long > step from "good constraint if we can meet it" to "must not." I wrote what seemed sensible to me. I was not implying it was consensus in the RRG. - 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
