[arin-ppml] Opposed to 2010-9 and 2010-12

Owen DeLong owen at delong.com
Wed Oct 13 20:45:17 EDT 2010


On Oct 13, 2010, at 5:20 PM, Leo Bicknell wrote:

> In a message written on Wed, Oct 13, 2010 at 03:51:51PM -0700, Owen DeLong wrote:
>> This applies to DSL and FTTH. It also applies to some of the CMTS
>> systems that are still running on DOCSIS 2.
> 
> I want to take a technology diversion here, because I think it's
> critical to the magnitude of the problem we are talking about.
> 
> If you're a DOCSIS 2 cable provider, you can:
> 
>   a. Deploy a DOCSIS 3 head end, which is widely available,
>      and deploy new DOCSIS 3 CPE, which is widely available.
>      The head end upgrade also gives you increased capabilities in
>      other areas.
>   b. Deploy a 6rd "head end" system in your core network, and
>      deploy new CPE, either a new modem that speaks DOCSIS 2/3 + 6rd,
>      or worse an additional box behind the current modem.
> 
> I'm having a hard time why anyone would ever pick b.  Similar
> level of effort for less capabilities going forward.
> 
It is actually slightly less effort, and, it depends on who you buy your
CMTS from. If you have some form of vendor lockin, a couple of
the vendors aren't quite there yet with DOCSIS 3.

TTBOMK, the ones doing b are deploying CPE that is DOCSIS2/3+6rd.

> I can't speak to FTTH in detail, don't know enough about it.  My
> limited understanding was the head ends were native v6 capable
> today, the issue was all CPE, and that much of the current CPE
> worked in briding mode.  Of course that's not the preferred deployment
> model, they usually deploy in router mode, but it's still an all
> CPE problem.  Again, if it's new CPE that does native, vrs new CPE that
> does 6rd, why would 6rd even be considered?
> 
That depends.. Some of them have native IPv6, but, in forms that
are apparently not the way ISPs want to deploy it. I don't understand
all the details completely either, but, the ISPs actually deploying it
that came up to talk to me convinced me they had a real problem.

> You would think DSL providers would be in a similar situation to the
> DOCSIS 2 cable providers above, but they are not, due to two fundamental
> differences.
> 
>  1. IPv6 standards came late to DSL.  My understanding is the first
>     standards based DSL gear was demonstrated in the field at the end
>     of 2009, years after cable.  What's more, not all DSL vendors have
>     IPv6 across their product line yet, so if you have particular
>     chassis you may not be able to buy the gear at all.  I even believe
>     there are some chassis that cannot be upgraded, so it is a
>     forklift.

In fact, no DSL vendor has IPv6 on their product line in a manner that
matches the IPOE deployments that providers are going to.

>  2. DSL has a one-to-one port mapping.  Unlike cable where upgrading
>     a single head end CMTS might enable hundreds or thousands of users
>     in DSL each line upgraded must be upgraded on both the head end and
>     customer end.  Thus there is an order of magnitude more head end
>     ports to upgrade, and with the gear not yet, or just now becoming
>     available even if they wanted to deploy it manpower and
>     maufacturing capacity are real issues.
> 
Yes and no... You can upgrade the DSLAM independent of the CPE
attached to it, but, you need to also upgrade the CPE to get benefit.

This is also true of CMTS.

> If I have any of this wrong, I'd love more details from folks in the
> know.  It goes directly to two important issues, the order of magnitude
> of how many folks will request space under this plan, and also how
> temporary the space will be used.  If it really is that much cheaper to
> deploy 6rd than upgrading a DOCSIS 2 cable plant to DOCSIS 3 that tells
> me this is going to stick around for a very long time for cost reasons.
> 
I figure plan on about 3,000 ISPs overall.

>> I can't advocate the ultra small subnets. That punishes the end users
>> for the mistakes of the provider's vendors. I can't advocate huge fees,
>> either since that also would unfairly penalize the end-user for mistakes
>> well outside of their control.
> 
> If the customers had no choice I would go with the word punish.
> I'm going to assume most customers have alternatives (and yes, I
> realize most there is a percentage even I have trouble calling
> most), and thus it gives them an incentive to find real connectivity.
> We're likely not to agree on this point though...
> 
Yep.. In fact, we thoroughly disagree. For example, the choice
in much of California, indeed, MOST of San Jose, the 3rd
largest population center in California boils down to a choice
between CMTS (admittedly DOCSIS 3) and ADSL2+ or less.
If you for any reason don't want to do business with Comcast,
or want a static IP address, then, your only choice is DSL.
If you want more than about 2Mbps, then, for most of San Jose,
your only choice is Comcast.

It's a lot bleaker in terms of consumer choice out there, even
for MOST consumers than you would like to think.

>> While that's true, I think we have to provide the bail-out. Penalizing
>> the end-user for the mistakes made primarily by their provider's
>> vendors is bad policy in my opinion. I'd love to see a way to
>> penalize the vendors in question, and, if you have one, I'm all
>> ears.
> 
> This probably won't fly as policy, but, let me give it a shot. :)
> 
>   Any address space provided by ARIN for 6rd will not be issued
>   until the recipient delivers one engineer and one executive from
>   the provider of the majority of their non-IPv6 capable equipment
>   to an ARIN public policy meeting to receive a public flogging.
>   The recipient must provide baseball bats for all policy meeting
>   attendees.
> 
I like it, but, I suspect you are right that it wouldn't fly as policy.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/de626422/attachment.htm>


More information about the ARIN-PPML mailing list