Re: Call for v6ops agenda items

[Cameron Byrne <cb.list6@gmail.com>]

On Wed, Feb 17, 2010 at 12:32 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 16 Feb 2010, Cameron Byrne wrote:
>
>> That means there are 2 of us now.  Does that make it relevant
>> conversation?  Keep in mind, if it is hard coded in ipv6 in 2010 make
>
> I have changed my mind.
>
> Looking at the scalability figures for current LTE architecture, your whole
> network will melt down before you even get CLOSE to 4 billion bearers, and
> even if you scale it past that, you just get a /30 instead of /32 and you
> can now have 16 billion simultaneous bearers.
>

Can you help me understand the scalability limits you are referencing?
 My expectation is that we deploy EPC PGW for LTE devices to start,
but eventually all 2G and 3G will be anchored on the regional PGW to
support iRAT handover.  Thus, the PGWs that we deploy in LTE will
terminate all data sessions from 2G/3G/4G ... LTE/EPC of today is
barely what UMTS release 99 was in terms of maturity... so there is
plenty of room for evolving to meet scalability challenges.

Granted, i am not explicitly anticipating growth like that in the near
future, but lessons from the past tell us exponential growth is a
reality, and we will have to evolve the technology to fit.   The
numbers i gave are a first swag at doing something that is both
practical and "future proof".   Honestly, that will likely be the
address structure i use in my network, 4 billion bearers or not.   I
am also very interested in the idea of cell site local PGW functions,
such that each cell site can do local handoff of IPv6 internet traffic
instead of backhauling to my mobile network aggregation site.  That is
a separate discussion and perhaps a special case, but if each cell
site has a PGW function and is handing out its own set of /64s, it
exacerbates the problem further... yes, there are lots of IPv6
addresses to be had.  And, no i don't think privacy addresses and
SLAAC and the other goodies that come with /64 are very valuable.
That's a value decision, to each thier own ... unless 3GPP says you
have to do /64 and vendors hard-coded it, which they did.

As one of the other folks pointed out, now is the time to deploy ...
but i tend to think folks have been saying that for 10 years now. At
least, i have heard it for 10 years now, and have told people it for
10 years now (this coin has 2 sides).  I loath to have to repeat the
lessons of classful IPv4 addressing, and as I have pointed out with
references early in this thread, /64 is being reject for point to
point links by many major ISP backbone and content network operators.
But, the 3GPP used a MUST for /64 when I believe they should have used
a SHOULD.  Que sera, sera.

Since it seems to need to be explicitly stated:  Thanks for your
opinion, i respect your comments, and please share the LTE bearer
scaling concerns.

Warmest Regards,

Cameron

> Let's stick with /64 for simplicity and for all the other reasons stated
> before. Let's focus on getting DHCPv6-PD etc working over this /64 instead,
> much rather put effort into that than trying to get smaller netblocks into
> the standard. It also simplifies filtering etc, the standard model today
> indicates that enduser /64 is a subnet with one or more devices within the
> same administrative entity, let's stick to that.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>