RE: [RRG] Moving forward... IPv4 now, IPv6 less urgent and perhaps more ambitious

["Tony Li" <tony.li@tony.li>]

Hi Robin,
 

|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?



|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?


|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.  ;-)


|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.


|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.


|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 - 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.

Note that fixing the routing architecture in v6 would aid its adoption.


|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.
;-)


|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.


|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.

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 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.


Tony


--
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