[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Moving forward... IPv4 now, IPv6 less urgent and perhaps more ambitious
Hi Tony,
You wrote:
> |There is a potential routing scaling problem because the IPv4 and
> |IPv6 routing systems are identical in respect of the limitations
> |which give rise to the problem. However the IPv6 system does not
> |have the physical problem so far because very few people use it.
>
> So you suggest that we wait until the problem is critical before we fix it?
No - I suggest we don't rush into fixing a future IPv6 problem while
the IPv4 problem costs hundred of millions (probably billions) of
dollars, restricts the availability of multihomable address space
and so needs fixing in the 2012 to 2015 time frame.
Since an IPv6 solution can be developed with a broader range of
techniques in a longer time frame, I suggest that by the time an
IPv6 solution needs to be decided upon, we should have a lot more
experience in the IPv4 solution than we do now.
This way, the IPv6 solution would not be frozen before it needs to
be and could benefit from IPv4 experience. I guess that decisions
about how different the IPv6 solution is from the IPv4 one, and how
many other goals such as solution should support, need only be made
when the IPv6 DFZ routing table looks like it is going to become
problematic four or five years from that time.
> |If your view reflects consensus in the RRG, then perhaps we could
> |form rough consensus on something like this:
> |
> | While some architectural enhancements could solve the routing and
> | addressing problem by creating a new kind of address space which
> | is portable, multihomable etc. without significantly burdening the
> | BGP system, we believes that none of them could be practical or
> | cost-effective enough to warrant development or deployment for
> | IPv4, compared with letting the current system saturate towards
> | 16M individually routed /24s.
>
> That seems a bit overboard. Precluding possible good ideas doesn't seem
> like it makes sense either and we certainly can't be sufficiently assured of
> our position to say that "none" of them could be practical. Doesn't that
> seem like it's a bit absolutist given that we've barely scratched the
> solution space?
My indented text above was my attempt to formalise what I understood
by what you wrote:
> There's no hurry to fixing it for IPv4 because frankly, we can
> scale the hardware to support the usual PI prefix sizes (/24 ->
> 2^24 routes == 16M routes). Yes, it will cost a bit more, but
> over the long run, that's probably a lot cheaper than upgrading
> every CPE or PE router.
which I interpreted as meaning that there was no need to fix the
IPv4 problem at all. I figured you meant to let the IPv4 system run
as is, to the point where there was finely divided address space for
PI space for many more end-user networks than at present, with
consequent scaling problems in the BGP system regarded as being
acceptable, due to them being "a lot cheaper than upgrading every
CPE or PE router." I thought that by this you meant, in effect:
a lot cheaper than upgrading every PE router, which is typically
what happens with a map-encap scheme to build ETR and perhaps
ITR functions into the ISP networks there.
So I understood your statement as meaning that the IPv4 problem was
not amenable to an acceptable solution by any means we currently
know of, including the map-encap schemes. My understanding of this
position is that you are much more optimistic about IPv6 adoption
than I am.
> |You are suggesting the current DFZ size of 250k:
> |
> | http://bgp.potaroo.net Ooops make that ~260k . . .
> |
> |should be allowed to grow a factor of up to 64 without any changes
> |in the BGP system or any architectural enhancements.
>
> I'll just point out that the table has grown by a factor of 50 since I
> started working in core routing. ;-)
Sure, but I think many people expect us to recommend a solution for
IPv4 in a time frame shorter than that those 15 or more years!
The size is approximately doubling every 4 years, but I expect this
time to shorten to maybe 2 years after about 2010 when IPv4 space is
much more finely and carefully divided than at present.
This cranks up the cost of DFZ routers - costs which flow to all
Internet users and place further pressures on how hard it is for an
end-user network to get PI space and advertise it as it needs to for
multihoming and TE. This further increases the cost of running
end-user networks, which winds up burdening many end-users directly,
and the taxpayers and customers who indirectly pay the costs of
those end-user networks.
> |I understand that for considerable, but perhaps not unthinkable,
> |expense the 200k+ (and more in the future) DFZ routers could be
> |upgraded to have FIBs to handle this. My first suggestion (early
> |2007, now abandoned) for the routing scaling problem:
> |
> | http://www.firstpr.com.au/ip/sram-ip-forwarding/
> |
> |was just this, when I thought that the FIB was the problem, not the
> |RIB and the associated BGP communications.
>
> As I think we've noted elsewhere as well, the RIB issues will continue to
> scale upwards with ever increasing costs and complexity at the BGP level as
> well. More generally, it seems like most scaling problems can be
> forestalled by the extreme application of cash. This suffices as a short
> term strategy while we produce a clean longer term solution.
Perhaps you could be more specific about years and outcomes.
My guess is you mean something like this, assuming the DFZ doubling
time reduces to 3 years after 2010, which I think is a very
conservative estimate:
IPv4: IPv6:
Do nothing and let
DFZ size grow to:
2009 310k
2010 370k Develop solution
2011 466k
2012 587k Deploy solution
2013 740k
2014 932k
2015 1175k But it is still cheaper and
2016 1480k better to upgrade IPv4 DFZ routers
2017 1864k than to try to run an ISP with
2018 2350k customers only having IPv6
2019 2960k addresses - so IPv4 remains
2020 3730k the real Internet and IPv6
2021 4699k adoption remains limited.
2022 5920k
2023 7460k
I think most (every?) ISPs and end-user network operator expects
there to be a solution to the IPv4 routing scaling problem and the
closely associated difficulty getting new address space in the 2010
to 2015 time frame. (The current BGP-based address space management
system prevents full utilization by preventing fine splitting of
space into chunks smaller than 256 IP addresses or numerous enough
to meet the needs of hundreds of thousands, millions or billions of
end-user networks.)
With or without such a solution, I think it will still be impossible
to attract end-users to IPv6-only services, since such a service
can't provide all their needs. Even if an IPv6-only service
provided for 90% of their needs, the support costs would make it
prohibitive compared to using NAT and finer slicing of IPv4
> |My understanding of your suggestion is that it is much the same as
> |my now-abandoned solution: flat routing to /24 with souped up
> |SRAM-based FIBs and hoping that Moore's Law would affordably provide
> |the extra CPU and RIB RAM grunt required to handle the up-to 64
> |times increase in the number of conversations each DFZ router needs
> |to have with each of its peers.
>
> Not necessarily completely flat to /24. Rather, we could just allow v4 to
> play out organically and let the current system of checks-and-balances cause
> some signficant pain for others while we deal with the longer term issue.
This is a good example of what I think is the extremely unrealistic
expectations amongst some folks about:
1 - How easy it will be to get anyone to adopt an IPv6 service
and run dual-stack with at least some major apps using IPv6.
2 - How soon the proportion of hosts with IPv6 connectivity could
get to the very high level (99%? 99.99??) required for
ordinary end-users to be happy with an IPv6-only service.
(This would presumably require most applications to have been
upgraded to IPv6.)
3 - The difficulty with which IPv4 space can be utilized much more
efficiently than at present. It is not that difficult with
the existing NAT and BGP techniques, just ugly and expensive
- but not prohibitively so compared to trying to sell an IPv6
only service. Map-encap and NAT would be less ugly and highly
scalable.
I think this high level of optimism about IPv6's usefulness to
ordinary users, and about how rapidly it will be adopted, is held
primarily by people with close association with the IETF rather than
amongst ISPs or ordinary end-users.
That optimism has been around since about 1995 but has not yet been
reflected in end-users or ISPs wanting, needing or adopting IPv6. I
don't think IPv4 routing or address difficulties are severe enough
to drive people to adopt IPv6 any time soon.
However convoluted and difficult English gets, it doesn't motivate
significant numbers of people to abandon the language and use
Esperanto instead.
I don't think the RRG can reasonably assume such optimism about IPv6
is realistic. That is why I wrote:
We can't bet the Internet on the imminent adoption of IPv6
http://psg.com/lists/rrg/2008/msg01373.html
just under 2 weeks ago.
> |Surely enough was agreed at RAWS about problems with BGP stability
> |and the load on CPUs and RAM to make your suggestion of leaving IPv4
> |alone a non-starter.
>
> As one of the primary protagonists at RAWS, I can assure you that there was
> nothing said at RAWS that excluded that option. In fact, I believe that
> that exact option was raised at the time.
OK - I wasn't there.
> |OK - we don't yet know when an IPv6 solution will be necessary.
>
> The eventual depletion of the address space suggests that it will happen,
> eventually. It may require many rounds of NATing and other such
> contrivances before v6 seems less painful, but there is no obvious assurance
> that we can make v4 viable indefinitely. Thus, at some point, v4 will end
> up being less attractive than v6 and some dual stack deployment would begin.
I think you are advocating letting the entire Internet-using world
suffer and stew in an uncared-for IPv4 Internet until the costs are
so great that some end-users find it better to adopt a new Internet
which doesn't connect properly to the old one.
I think this is unrealistic and that the RRG can and should do better.
Here are two statements which I think are true now and will remain
true, despite the IPv4 address depletion problem, because there are
always going to be ways of incrementally splitting up IPv4 space
finer and using more NAT, which will be better than trying to sell
an IPv6-only service which doesn't do what people want, in
competition with other ISPs who sell a fully functional IPv4 service:
A - There's no reason for ordinary end-users to adopt IPv6 -
dual stack or IPv6-only because it does not enable them to
communicate with any host of interest which they can't already
reach perfectly well via IPv4. (China and cell-phone systems
are significant possible exceptions.) There will be no reason
for ISPs to sell IPv6 only or dual stack services for these
reasons - or for most end-users to adopt them if they were
on offer - as long as most people's computers have an IPv4
connection.
B Most (all) end-users will use IPv4 until most (almost all?)
end-users have a pure IPv6 or a dual stack service.
There's no way out of this as far as I can see.
If you propose that the RRG solution depend on mass adoption of
IPv6, I think you need to counter arguments such as mine about why
this won't happen in the foreseeable future, and propose some time
frames and mechanisms by which you think we can all be reasonably
certain the mass adoption and migration will take place.
> Note that fixing the routing architecture in v6 would aid its adoption.
I don't see why, since end-users don't care and ISPs won't care
until the IPv6 DFZ routing table became large enough that their
routers cost too much. But even that is assuming a level of IPv6
adoption which I cannot imagine happening in the foreseeable future.
In the absence of widespread adoption of map-encap for IPv4 the
bloated and still growing IPv4 DFZ routing table would be driving
the rapid development of DFZ routers with huge RAM and CPU
capabilities. Since these same routers would generally also be
handling IPv6 traffic on the same long-distance links, I find it
hard to imagine IPv6 adoption being so advanced as to lead to such a
large DFZ routing table size that the cost problems of fielding DFZ
routers for IPv6 traffic beyond the costs already involved in
fielding IPv4 DFZ routers would be a motivating factor for ISPs.
The above scenario applies if the IPv6 DFZ routing table grows to
rival the size of the IPv4 one - yet your argument is about a
routing scaling solution for IPv6 encouraging early adoption of
IPv6, well before the IPv6 DFZ routing table could have grown to
such a size.
> |As I suggested, I think we would be doing our job well if we
> |suggested several promising approaches to IPv6, since there is no
> |urgency about deciding on which should be developed and deployed. I
> |think the situation with IPv4 is urgent enough that we should find
> |the most promising solution, or class of solutions, and recommend
> |that for immediate development. Perhaps we won't reach consensus on
> |one, but there may be considerable support for two solutions. If
> |so, that is the best we can recommend. If we can't reach much
> |consensus on anything, then I think our report should reflect that.
>
> If we can't reach consensus, there's not much point in writing the report.
> ;-)
Except to outline our attempts and try to present the viewpoints of
the various sub-groups of people, none of whom were large enough and
none of which had sufficient commonality of views to form a consensus.
That would not necessarily a failing of the co-chairs or of the RRG
in general. It may turn out that in 2008 to early 2009, amongst any
reasonably competent group of people in this field, that there is
currently not enough agreement on the problems, the urgency of
solution, the linkage to other goals or the merits of the various
suggested solutions to form consensus on anything - much less to
recommend any one solution, or architectural approach, for
engineering development.
> |Yes, but I would be surprised if there is consensus that the IPv4
> |routing and addressing problem is so inconsequential that we don't
> |need to recommend a more specific and better researched solution for
> |IPv4 than we do for IPv6.
>
> Exactly why I'm testing the consensus.
Yes - and why I am proposing an alternative which I think would be
agreed to by the map-encap developers at least, and hopefully many
other folks.
> |OK. Based on recent messages of support for Tony's text, I am
> |surprised by how many people seem to think we don't need to solve
> |the IPv4 problem.
>
> And some of us are equally surprised that there is such a fervent desire to
> provide a v4 solution.
And some of us are surprised that anyone is surprised that some of
us think it is important to keep the current Internet working, given
that:
1 - There do seem to be ways of doing it scalably (map-encap).
2 - Even without map-encap, it will still be kept going despite
problems with routing scaling and with shortage of PI space
for large numbers of end-user networks who would have been
able to get it scalably with map-encap.
3 - The only currently available alternative (IPv6) is not directly
connected to or fully compatible with the IPv4 Internet, in
terms of communications between hosts, in terms of application
protocols or in terms of many existing applications.
4 - While IPv6 (as in the past 13 years since its inception)
provides nothing that end-users or ISPs actually want or need.
> The discussion of our basic underlying differences is the only way that we
> will ever create movement within the community and thus reach consensus. If
> all we do is sit in our entrenched positions and endlessly reiterate the
> benefits of the respective proposals, we are guaranteed to accomplish
> nothing in establishing consensus.
I think the discussion has been productive because it has helped
both camps realise there is another camp with very different ideas -
whereas before, I think we tended to assume we were all pretty much
in agreement.
My proposed text is supported by Bill Herrin and somewhat supported
(IPv4 is a must, but with the same techniques as IPv6) by the APT team:
http://psg.com/lists/rrg/2008/msg01458.html
Your position:
Ok, take 2:
Our recommendation should be applicable to IPv6. It may or may
not also apply to IPv4, but at the very least must provide a path
forward for IPv6.
is supported by quite a few people, including Noel Chiappa, Joel
Halpern, Olivier Bonaventure, David Williamson, Ran Atkinson, Brian
Carpenter, Bob Hinden (what does WFM mean?) and Marshall Eubanks.
Fred Templin disagreed with your text, wanting IPv4 and IPv6
solutions. Scott and I think Dino disagreed with an earlier version.
Unless there is a significant majority in favour of one or the other
positions - that we need to recommend an IPv4 solution or not - then
I think the RRG can't reach consensus on anything much, since the
answer to this question is a fundamental basis on which we make most
other decisions. It affects the goals, the techniques available and
the time frame.
Fixing the IPv6 routing scaling problem in sufficient time is easy.
It may be as easy as doing absolutely nothing because maybe IPv6
will never be used enough to have a routing scaling problem.
Even assuming IPv6 is somehow widely used by 2020, it is an easy
problem to solve compared to IPv4, since there is no urgency, and
since there are lots of address bits to play with - and lots of
space to splash around.
Fixing the IPv4 problem is what the map-encap folks tried to do.
Each of us think we have achieved a promising approach, though we
favour our approach over the others.
If the RRG can't form consensus that any one such map-encap approach
is suitable for IPv4, then so be it.
However, if that decision is based on what I regard as a completely
unrealistic notion of IPv6 adoption - as I think your position is
based on - then I think that consensus would be on a faulty basis
and would not be widely understood or respected by the rest of the
world who care a lot about IPv4 and have little or no reason to be
enthusiastic or optimistic about IPv6.
> |I think we all went to a lot of trouble
> |to develop our solutions because we believe something really is
> |needed ASAP for IPv4. That was the impetus behind the RAWS workshop
> |20 months ago.
>
> I beg to differ. The impetus behind RAWS was to fix the architecture, not
> necessarily the protocol. My personal agenda (shared by a few others, I
> think) was to reopen the case for GSE, for example. Please stop projecting
> your views onto others that you don't represent.
OK.
It is my impression this was the impetus behind RAWS, but I wasn't
there. Perhaps I am mistaken.
- 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