<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 13, 2010, at 5:20 PM, Leo Bicknell wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>In a message written on Wed, Oct 13, 2010 at 03:51:51PM -0700, Owen DeLong wrote:<br><blockquote type="cite">This applies to DSL and FTTH. It also applies to some of the CMTS<br></blockquote><blockquote type="cite">systems that are still running on DOCSIS 2.<br></blockquote><br>I want to take a technology diversion here, because I think it's<br>critical to the magnitude of the problem we are talking about.<br><br>If you're a DOCSIS 2 cable provider, you can:<br><br> a. Deploy a DOCSIS 3 head end, which is widely available,<br> and deploy new DOCSIS 3 CPE, which is widely available.<br> The head end upgrade also gives you increased capabilities in<br> other areas.<br> b. Deploy a 6rd "head end" system in your core network, and<br> deploy new CPE, either a new modem that speaks DOCSIS 2/3 + 6rd,<br> or worse an additional box behind the current modem.<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><blockquote type="cite"><div>I'm having a hard time why anyone would ever pick b. Similar<br>level of effort for less capabilities going forward.<br><br></div></blockquote>It is actually slightly less effort, and, it depends on who you buy your</div><div>CMTS from. If you have some form of vendor lockin, a couple of</div><div>the vendors aren't quite there yet with DOCSIS 3.</div><div><br></div><div>TTBOMK, the ones doing b are deploying CPE that is DOCSIS2/3+6rd.</div><div><br><blockquote type="cite"><div>I can't speak to FTTH in detail, don't know enough about it. My<br>limited understanding was the head ends were native v6 capable<br>today, the issue was all CPE, and that much of the current CPE<br>worked in briding mode. Of course that's not the preferred deployment<br>model, they usually deploy in router mode, but it's still an all<br>CPE problem. Again, if it's new CPE that does native, vrs new CPE that<br>does 6rd, why would 6rd even be considered?<br><br></div></blockquote>That depends.. Some of them have native IPv6, but, in forms that</div><div>are apparently not the way ISPs want to deploy it. I don't understand</div><div>all the details completely either, but, the ISPs actually deploying it</div><div>that came up to talk to me convinced me they had a real problem.</div><div><br><blockquote type="cite"><div>You would think DSL providers would be in a similar situation to the<br>DOCSIS 2 cable providers above, but they are not, due to two fundamental<br>differences.<br><br> 1. IPv6 standards came late to DSL. My understanding is the first<br> standards based DSL gear was demonstrated in the field at the end<br> of 2009, years after cable. What's more, not all DSL vendors have<br> IPv6 across their product line yet, so if you have particular<br> chassis you may not be able to buy the gear at all. I even believe<br> there are some chassis that cannot be upgraded, so it is a<br> forklift.<br></div></blockquote><div><br></div>In fact, no DSL vendor has IPv6 on their product line in a manner that</div><div>matches the IPOE deployments that providers are going to.</div><div><br><blockquote type="cite"><div> 2. DSL has a one-to-one port mapping. Unlike cable where upgrading<br> a single head end CMTS might enable hundreds or thousands of users<br> in DSL each line upgraded must be upgraded on both the head end and<br> customer end. Thus there is an order of magnitude more head end<br> ports to upgrade, and with the gear not yet, or just now becoming<br> available even if they wanted to deploy it manpower and<br> maufacturing capacity are real issues.<br><br></div></blockquote>Yes and no... You can upgrade the DSLAM independent of the CPE</div><div>attached to it, but, you need to also upgrade the CPE to get benefit.</div><div><br></div><div>This is also true of CMTS.</div><div><br><blockquote type="cite"><div>If I have any of this wrong, I'd love more details from folks in the<br>know. It goes directly to two important issues, the order of magnitude<br>of how many folks will request space under this plan, and also how<br>temporary the space will be used. If it really is that much cheaper to<br>deploy 6rd than upgrading a DOCSIS 2 cable plant to DOCSIS 3 that tells</div></blockquote><blockquote type="cite"><div>me this is going to stick around for a very long time for cost reasons.<br><br></div></blockquote>I figure plan on about 3,000 ISPs overall.</div><div><br><blockquote type="cite"><div><blockquote type="cite">I can't advocate the ultra small subnets. That punishes the end users<br></blockquote><blockquote type="cite">for the mistakes of the provider's vendors. I can't advocate huge fees,<br></blockquote><blockquote type="cite">either since that also would unfairly penalize the end-user for mistakes<br></blockquote><blockquote type="cite">well outside of their control.<br></blockquote><br>If the customers had no choice I would go with the word punish.<br>I'm going to assume most customers have alternatives (and yes, I<br>realize most there is a percentage even I have trouble calling<br>most), and thus it gives them an incentive to find real connectivity.<br>We're likely not to agree on this point though...<br><br></div></blockquote>Yep.. In fact, we thoroughly disagree. For example, the choice</div><div>in much of California, indeed, MOST of San Jose, the 3rd</div><div>largest population center in California boils down to a choice</div><div>between CMTS (admittedly DOCSIS 3) and ADSL2+ or less.</div><div>If you for any reason don't want to do business with Comcast,</div><div>or want a static IP address, then, your only choice is DSL.</div><div>If you want more than about 2Mbps, then, for most of San Jose,</div><div>your only choice is Comcast.</div><div><br></div><div>It's a lot bleaker in terms of consumer choice out there, even</div><div>for MOST consumers than you would like to think.</div><div><br><blockquote type="cite"><div><blockquote type="cite">While that's true, I think we have to provide the bail-out. Penalizing<br></blockquote><blockquote type="cite">the end-user for the mistakes made primarily by their provider's<br></blockquote><blockquote type="cite">vendors is bad policy in my opinion. I'd love to see a way to<br></blockquote><blockquote type="cite">penalize the vendors in question, and, if you have one, I'm all<br></blockquote><blockquote type="cite">ears.<br></blockquote><br>This probably won't fly as policy, but, let me give it a shot. :)<br><br> Any address space provided by ARIN for 6rd will not be issued<br> until the recipient delivers one engineer and one executive from<br> the provider of the majority of their non-IPv6 capable equipment<br> to an ARIN public policy meeting to receive a public flogging.<br> The recipient must provide baseball bats for all policy meeting<br> attendees.<br><br></div></blockquote>I like it, but, I suspect you are right that it wouldn't fly as policy.</div><div><br></div><div>Owen</div><div><br></div></body></html>