Re: [RRG] Consensus? 4 points so we can make progress

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Robin,

On 2008-05-28 13:54, Robin Whittle wrote:
> This will no-doubt displease some folks, but here is a set of points
> which I think we need to agree upon soon in order to make sufficient
> progress to achieve a useful recommendation in March 2009.
> 
> Without such agreement, or something similar, I think we would waste
> time arguing about:
> 
>    a - A solution which involves significant host changes - and
>        therefore which could never be implemented in a reasonable
>        time-frame.

We'd certainly waste time by arguing about it as an abstract principle.
But there is evidence that new TCP/IP stacks can be rolled out in the
major operating systems on a timescale of a few years, so I would be
prepared to consider a solution that includes incremental roll-out
to hosts. I think we agree that we're unlikely to invent a solution
that solely depends on that, however. In any case I suggest it's
already off the research table, since shim6 is already in the IETF
process, so not worth discussing here.

>    b - Router based translation schemes which can't be practical for
>        IPv4.  http://psg.com/lists/rrg/2008/msg01314.html

I think it's pretty clearly established that, due to the shortage
of IPv4 prefixes, either map-and-encap or pure NAT is *required*
for IPv4, iff we believe that the remaining scaling of IPv4 usage
will actually exceed BGP4 scaling capability.

However, I would observe (even as a well-known NAT hater) that we
have *already* broken the IPv4 transparency model by widespread use
of NAT. So one can legitimately ask: does it really matter if we
break IPv4 transparency even more by deploying much more NAT?

What I'm getting at is that it doesn't follow that we need the same
solution for IPv4 as for IPv6. We could consider "doing it right"
for IPv6 and struggling on with NAT for IPv4. (I can't believe I
just wrote that ;-( )

>    c - The prospects for near-term (next 5 years or so) widespread
>        adoption of IPv6 - because we haven't formed a clear
>        consensus that we need to solve the IPv4 routing scaling
>        problem directly, but think it could or should be solved by
>        mass migration from IPv4 to IPv6.

I haven't used the word 'migration' for years in that context. The model
is very clearly one of long-term *coexistence* of v4 and v6. So
v6 deployment is definitely not an excuse for ignoring v4 scaling.

> 
> 
> Here is the rough list of points, all of which have been discussed
> in greater detail in recent days:
> 
> 1 - The scope of the RRG's work should focus on IP addresses and
>     network based solutions - involving new router functions
>     and/or new network elements.  The solution should not involve
>     any changes to host stacks or applications, except perhaps
>     to optimise performance which is degraded by the main solution.

I mainly agree with that. Some host based approaches (shim6 and sctp)
are already in standards development. However, I think we should
have ILNP on the radar screen.

> 
>     Discussion of longer-term architectural solutions involving
>     changing or underpinning existing host-level protocols -
>     necessarily involving changes to host stacks and/or
>     applications - should be directed to another forum.
> 
> 
> 2 - The solution must work for IPv4 and IPv6 and show promise
>     for being adopted by the majority of end-user networks
>     in the 3 years following deployment, such as in the 2012 to
>     2015 time-frame.  While this adoption will be supported and
>     encouraged by administrative and perhaps business arrangements,
>     the primary reason for adoption will be the immediate benefits
>     to the ISPs and end-user networks.

See above comment re different solutions for the two cases.
> 
> (We don't have a good definition of "end-user networks", but I
> suggest it should include all sizes - existing and new - including
> single-host networks: from the largest universities and corporations
> down to individuals on DSL lines and with cell-phones.)
> 
> 
> 3 - The solution must provide portable address space for
>     end-user networks without impacting the scaling of the
>     current BGP routing system.  (The map-encap schemes do this.)

I don't agree. The desire for "portable" prefixes is an artefact of
IPv4 experience. Let me reformulate.

     The solution must allow the option of provider-independent
     address space and the option of multiple provider-dependent
     address spaces for end-user networks...

I don't think we should constrain the future in a way that IP does
not do today.

> 4 - As already agreed, the solution needs to support multihoming
>     and traffic engineering in a scalable fashion.

Yes.

    Brian

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