[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Long term clean-slate only for the RRG?
Hi Robin,
Below is just a quick reply based on *personal* view.
I would like to first sort out a few basic things.
- yes we want to/need to "get it right"
- a clean-slate way of thinking is to see the complete design space,
without being constrained by what is "doable" or "undoable".
- it will take a great engineering design decision to choose
among alternative solutions, based on the tradeoffs,
short term vs long long term.
a few more points in line
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.
I am not sure what to make out of this statement.
- does it imply that such solutions would not be deployable?
- Isn't map-encap an entirely new scheme (compared to what we have
today)?
but does it require an "entirely new 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.
Robin, as you saw from the exchanges, there are a number of different
views regarding "start with IPv6" position.
I feel the most productive thing to do is to identify commonalities in
the group.
I don't see the need to use an magnifying glass over differences or
searching for holes in opposing views.
The most substantial solutions to the routing scaling problem
proposed so far are:
LISP-NERD
LISP-ALT
APT
Ivip
TRRP
Six/One Router
From architectural view, I'd identify the commonality of all the
above as stopping topology-aggregatable prefixes at the boundary of
edge sites, not which version of IP they may/not work with.
......
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.
I failed to comprehend the above paragraph, as it seems to suggest
long term solution and map-encap are exclusive to each other---not
sure where this came from.
I'll save the rest for later (as it's getting close to 3AM local
time). But I'd like to repeat myself one more time here:
- we are solving routing scalability problem here.
we need to "do it right"
- Lets not throw "Long Term Clean Slate" rock to others.
- exaggerating differences does not help progress.
- architectural changes and increment deployment do not have to
be exclusive to each other.
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)
Internet.
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
http://psg.com/lists/rrg/2008/msg01574.html
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
time-frames.
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.
- Robin
--
to unsubscribe send a message to rrg-request@psg.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
--
to unsubscribe send a message to rrg-request@psg.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