[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Practical proposals vs. endless theoretical discussions
- To: Routing Research Group <email@example.com>
- Subject: [RRG] Practical proposals vs. endless theoretical discussions
- From: Robin Whittle <firstname.lastname@example.org>
- Date: Fri, 12 Sep 2008 18:33:16 +1000
- Cc: email@example.com, Dino Farinacci <firstname.lastname@example.org>
- Organization: First Principles
- User-agent: Thunderbird 18.104.22.168 (Windows/20080708)
Short version: In 13 months I think the RRG has made no real
progress towards a meaningful recommendation for
scalable routing. This is nearly 2 years after
RAWS and 6 months from our March 2009 deadline.
There are potentially practical proposals - LISP,
APT, Ivip, TRRP and maybe Six/One Router. However
these arose independently of the RRG and are rarely
discussed. Most talk is of clean-slate designs,
flat routing, ILNP etc. which have nothing to do
with our need to have something attractive to
end-users in the next 4 to 8 years to solve the
scaling problem in today's IPv4 Internet.
If we want to focus on clean-slate designs, we
should come up with either a transitional
scalability fix for the period we expect to
transpire before most networks adopt our clean
slate proposal - or show why no such fix is
really needed. Since no-one can reasonably be
sure of a clean-slate approach every being widely
adopted, that period needs to be at least 20 years
and probably indefinite.
> |> One word: translation.
> | The only translation scheme is Six/One Router, which can't work
> | for IPv4 and does not provide multihoming for packets sent from
> | hosts in non-upgraded networks.
> Or, ILNP with NAT. Or, for that matter, NAT alone.
ILNP is not mentioned on the RRG wiki:
It is for IPv6 only, and I recall it is a radical transformation of
IPv6 which involves changes to host stacks, APIs between the stack
and applications, and to the applications themselves. In my view
its practicality rating is indistinguishable from zero. Does anyone
really think we could attract everyone to changing their computers
to a new kind of IPv6, when there is no benefit in them doing so
until everyone else does the same? Also, wouldn't it require some
kind of renumbering, because it uses addresses in a very different
way? Since we are using IPv4 now, any transition to IPv6 involves
radical renumbering anyway.
NAT doesn't give portability or multihoming.
LISP and APT were are potentially practical proposals and were both
developed about 18 to 20 months ago. Ivip is 15 months old and TRRP
is a little younger.
Six/One Router is only for IPv6. Maybe it could be practical too.
All these are based on the assumptions:
1 - We can't force scalable routing technologies on anyone.
2 - We need the new system to be very widely adopted by end-user
networks large and small.
3 - There's no hope of widespread adoption if the system requires
host changes, particularly if the benefits only accrue to
communications between two upgraded hosts.
All but Six/One Router are based on the further assumption that in
order to be adopted widely, the system must provide full portability
and multihoming benefits for packets sent from hosts in non-upgraded
networks. LISP didn't have that until last year. APT has some
arrangement for this, which I think would work better if there was
only one global "APT island". TRRP has some kind of support for
NAT has no role in a scalable routing solution, unless you mean some
kind of NAT and mapping system. I don't understand what such an
approach is - I could never understand LISP-NAT:
See also the end of: http://www.firstpr.com.au/ip/ivip/lisp-links/
I have been proposing practical solutions since June 2007. They
don't get much discussion here. The two recent additions concern
forwarding packets to (IPv4) or towards (IPv6) using bits in the
ETR Address Forwarding (EAF) - for IPv4
Prefix Label Forwarding (PLF) - for IPv6
The gotcha is the DFZ routers need an upgrade, but that may well be
practical in the time-frame available. Both these techniques are a
major advance on map-encap due to there being no packet overhead or
PMTUD problems. They are also a lot less complex than Translation.
Apart from some helpful messages from Brian Carpenter regarding the
IPv6 Forwarding proposal, there has been no discussion of these at all.
Instead, month after month, there is lots of chat about theoretical
aspects of routing and potential Internet architecture which are
clean-slate designs, or involve host changes, which makes them about
as unlikely to ever be adopted as a clean slate design.
The RRG has achieved little meaningful consensus and has not been
supporting discussion of potentially practical proposals. I think
the recent vote on "renumbering" is meaningless, since recent messages
indicate that different people had differing understandings of what
they were voting for.
The consensus on mapping granularity being to an identifier level
condemns the mapping system and the FIBs and RIBs of ITRs in any
RRG-supported IPv6 scheme to handle bloated 128 bit addresses.
Ivip's granularity will be /64 - which meets all practical
requirements without overly burdening the ITRs or the mapping system.
Both these consensus items seem to involve elevating something which
is merely desirable to the status of being absolutely required in
any proposal the RRG would consider - without proper regard to the
practical consequences of such requirements.
If that is "architecture" - leaving some other mob of "engineers" to
sort out the implementation details - then it is an isolated and
irrelevant view of architecture which we should avoid like the plague.
Both consensus items paint the RRG into a corner where there is no
practical solution - though for the mapping resolution, the "host
identifier" consensus is practical for IPv4.
As the months go on I see no meaningful progress in what the RRG
agrees to and I think there is far too little discussion of
potentially practical proposals.
We haven't even developed consensus on a time-frame, or multiple
possible time-frames, for when a scalable routing system would have
to be deployed and gaining wide acceptance.
It is nearly two years since RAWS and 6 months before the RRG is
supposed to report its recommendations.
I think the proposals - LISP, APT, Ivip, TRRP and Six/One Router are
the primary progress which has been achieved - but this has been
independent of the RRG itself.
I don't think the RRG has made any significant progress in
discussions or in consensus items, unless it is to be assumed the
solution lies in a clean-slate approach. The outlook for clean
slate approaches is bleak. IT systems are very hard to change - and
the IPv4 Internet is the world's biggest and most significant IT
system, with no clean upgrade path to anything else - including to
IPv6, which is a separate Internet.
If the RRG is to contemplate only clean-slate designs, I think we
should first come up with a plan for how the Net is going to get
along without a scalable routing solution for the period until we
are confident the clean-slate design would be very widely adopted.
Since we can't reasonably be confident of widespread adoption of
IPv6, much less a clean-slate design, that time period would be
indefinite. So I suggest that if we want to talk about clean-slate
designs, or IPv6-based approaches with radical changes involving
host stacks and/or applications, then we must first either:
1 - Come up with a scalable routing solution for the Internet as
it really exists today - IPv4 - which will last indefinitely.
2 - Show why one is not needed: prove the problems discussed at
RAWS and which prompted the RRG's current work to be not worth
fixing for some indefinite period while we or our successors
develop a clean slate proposal.
Dino wrote in July: http://psg.com/lists/rrg/2008/msg01971.html
Well, one thing this list keeps doing is trying to draw the line
where architecture should stop leaving it for some other process,
say engineering, to make the really hard decisions. If the
architecture is too high-level and doesn't "draw a line in the
sand", then the practical architecture will happen after this
step in the process.
So you can't punt very many things or you become irrelevant.
I think the focus on so-called architectural level discussions -
avoiding the potentially practical proposals in favour of those with
greater architectural purity, but zero chance of adoption - is
avoiding the difficult practical matters in favour of an
interesting, but ultimately irrelevant, discussion.
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