[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Long term clean-slate only for the RRG?
- To: Routing Research Group <email@example.com>, firstname.lastname@example.org, Lixia Zhang <email@example.com>
- Subject: [RRG] Long term clean-slate only for the RRG?
- From: Robin Whittle <firstname.lastname@example.org>
- Date: Sat, 21 Jun 2008 12:59:31 +1000
- Organization: First Principles
- User-agent: Thunderbird 126.96.36.199 (Windows/20080421)
Hi Tony and Lixia,
You - or at least Tony - seem to be focusing on Getting It Right for
the long-term: forever. This surely requires a clean-slate
approach, with an entirely new routing and addressing architecture.
Perhaps you could start with IPv6 and make radical changes along
the lines of GSE - but the result would be something quite different
from IPv6 and would involve major changes to host stacks and
applications, and I guess to TCP, UDP, SCTP etc.
The most substantial solutions to the routing scaling problem
proposed so far are:
These are all intended by their developers to work for both IPv4 and
IPv6 as we know them today, without any host changes - other than
perhaps minor optional changes to help work around moderate inherent
performance problems in the pull-based map-encap systems. (I think
Six/One Router can't work for IPv4, but it is intended to.)
If you want the RRG to work solely on the Long Term Clean Slate
approach, that is fine. While I (and I guess the other map-encap
developers) would have something to contribute to that project, it
is not an urgent project - unless perhaps you want it to be the only
solution, which would make it much more urgent.
It would take many years to devise the optimal Clean Slate approach.
As part of doing so, you would need to incorporate transition
mechanisms which will enable the majority of end-users to be
attracted to it - even in the early days when few others use the new
system - rather than keeping going with the IPv4 (or perhaps IPv6)
Then it would take years to create all the new protocols in detail,
write the software, get it built into existing routers and hosts,
and to create new or radically re-written applications for the new
system. (You would need to have a plan for motivating application
programmers to make such huge investments, before many, or any,
users used the new system.)
A Long Term Clean-Slate project would be much more ambitious than
IPng - which involved minimal changes to host stacks and
applications compared to what you need to do. 12 or so years later,
that project has yet to achieve success.
I (and I guess the other map-encap folks) think that the current
IPv4 situation is important and urgent enough to warrant an IPv4
solution first, with a similar, but not necessarily identical,
solution for IPv6 to be deployed with less urgency. (I am not
suggesting the Net will melt-down in 2014, just that we are so far
from adopting IPv6, and that IPv6 isn't that exciting, that we need
to keep IPv4 going for a lot longer so we have the decade or so it
will take to devise something adoptable and long-term scalable.)
All the map-encap proposals were described initially in terms of
IPv4, with IPv6 details to follow later.
Maybe you could get the RRG to devise a Long-Term Clean Slate you
consider promising by March 2009, but I can't imagine you will
convince many people that what the RRG devises is so promising that
no other line of research of action needs to be taken.
I think you may be able to convince some IETF folks a
"Clean-Slate-only" approach was the way forward. However, I can't
imagine a sufficient number of end-users and ISPs would be confident
that a completely clean-slate approach would be developed, deployed
and very widely adopted in time to make it unnecessary to solve the
IPv4 and perhaps IPv6 scaling problems directly.
The parlous state of IPv6 adoption and of its transition mechanisms
shows how hard it is to migrate from IPv4 to some new network which
requires different host stack and applications, and which doesn't
connect directly to the IPv4 network.
Your new Clean Slate approach would be even harder to migrate to,
since the host stack and applications would be totally different,
not just marginally different - due to your need to devise a
completely different set of clearly separated identifiers, locators etc.
With only 9 months to go, I think the RRG needs to decide ASAP
whether we is only working on a Long-Term Clean Slate approach, or
whether we are pursuing several directions of research in parallel.
Until this is settled, I think we will often be discussing things at
cross purposes. For instance the recent exchange between Bill and
Tony, where Bill talked about the Net as it is today, and what is
required to support end-users who can't and won't change from this
approach in the foreseeable future, while Tony seemed to be
concerned only with the Long-Term Clean Slate approach.
I suggested some text - points A, B and C - we might agree to
regarding multiple paths of research in a recent message:
3 potential consensus questions
Here are some other options if C can't be agreed to:
D: No IPv4 solution - single Long-Term Solution.
Devise single lasting solution which may be applicable
as a major revision to IPv6 or which may require a completely
new Internet architecture, protocols, applications etc.
E: Devise an IPv6 solution but not an IPv4 solution.
Work on a solution for IPv6 without major changes (this rules
out GSE or major changes to protocol, stack, apps etc.)
As this work progresses, decide whether this will be good enough
for the Long Term. Either adapt it to be so, or regard scalable
IPv6 as the near-term solution, while we devise a separate
Long Term Clean Slate architecture.
F: No IPv4 or IPv6 solution. Devise purely a Long-Term Clean Slate
solution, which has no basis in IPv4 or IPv6.
I like Bill Herrin's comparison with the Manhattan Project. What we
are trying to do is so far from a clear solution, yet Something
Definitely Needs To Be Done and there are many uncertainties about
what is technically possible, and what is adoptable in various
I think there are too many uncertainties at present not to pursue
multiple parallel streams of research.
Maybe you only want to conduct the Long-Term stream on the RRG.
to unsubscribe send a message to email@example.com 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