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

[Leo Bicknell]

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.

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?

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

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

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

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/60777b31/attachment.sig>