[arin-ppml] New Policy Proposal
Bill Sandiford
bill at telnetcommunications.com
Thu Aug 16 13:01:57 EDT 2012
Bill,
I'll also note that ISPs in Canada have been dealing with this issue for quite some time. If you recall, representatives from a large Canadian ISP (Teksavvy Solutions) first appeared at the ARIN meeting in Atlanta in 2010 and discussed this issue at the open microphone session. Canadian ISPs have been working hard since that time to try and come up with some solution for this that wouldn't require us to come to the community requesting a policy change. 2 years have elapsed and we have been unable to resolve this matter in any other fashion and the market failure condition remains.
Bill
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Sandiford
Sent: August-16-12 12:50 PM
To: 'William Herrin'
Cc: John Curran; arin-ppml at arin.net
Subject: Re: [arin-ppml] New Policy Proposal
Hi Bill,
Your analysis on 1 thru 4 is very close. The only thing that I would say is that the nodes aren't empty in all cases. They may have 1 or 2 customers on them, but still very underutilized. In some cases they could be empty though.
I'm not sure I would say the Cable Companies tricked the CRTC into anything. The CRTC established a framework for third party access, and the cable companies were given the latitude to decide how to implement it. Naturally they chose an implementation that was similar to their own implementation for retail customers, namely assigning pools to nodes and handing out addresses by DHCP.
The other process that John mentioned was a totally separate process. Because of the limitations of the DHCP methods (namely that all assignments to end users are dynamic), the competitors went to the CRTC to ask that the cable companies be forced to provide a method by which competitors could provide static IPs to their end users. The CRTC agreed and mandated that static IP allocation should be made available to competitors for a variety of reasons with the main reason being that cable companies were providing static IPs to their own customers and shouldn't be able to confer upon themselves a competitive advantage. As usual, the CRTC stayed out of the technical "how to do it" issues and deferred it to the CISC NTWG group (of which I am a member) to come up with a solution. Ultimately that group recommended 2 technical solutions to the commission for static IPs, namely Managed Routers and L2TP tunneling and the CRTC approved these methods. Although these methods are appr oved by the CRTC they have not been implemented by the Cable Carriers yet. It is also very important to note that these solutions were very specific to the assignment of STATIC IPs only. These methods do not apply to the overwhelming majority of end users.
So just to be clear, we can only select the L2TP and/or Managed Router solution for customers that request static IP addresses, if and when the cable carriers implement those solutions and they come available.
I'll also note, as you can read in the CRTC decision, that we tried in this process to ensure that the cable carriers committed to a IPv6 compatible solution but they resisted and the CRTC declared that request as out of scope and denied it.
Regards,
Bill
-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: August-16-12 12:12 PM
To: Bill Sandiford
Cc: John Curran; arin-ppml at arin.net
Subject: Re: [arin-ppml] New Policy Proposal
On Thu, Aug 16, 2012 at 11:18 AM, Bill Sandiford <bill at telnetcommunications.com> wrote:
>> Given that addresses from these per-node pools are dynamically
>> allocated to subscribers, is it possible for the cable company to
>> reprovision the address space from the ISP's other underutilized
>> nodes as needed? (This is what is expected from all other ISPs in
>> similar situations under the present policy.)
>
> Good question. Unfortunately the answer is no. In most cases the
> allocations on the other underutilized nodes is already a /29, so
> reprovisioning those other nodes to a /30 isn't practical. To my
> knowledge the cable companies require all nodes to be numbered.
Hi Bill,
So the nutshell of this problem is:
1. The cable company has 1000 or so nodes to which Internet access customers connect.
2. The competitive ISP is required by the _cable company_ to initially provision all 1000 nodes with IP address pools regardless of whether they then have or later acquire customers connected to each node.
3. Although node pools could, technically, be provisioned upon acquisition of the ISP's first customer at that node, the cable company declines to permit it.
4. Most nodes are still empty of customers when the ISP runs out of its initial allocation, leaving it very underutilized per ARIN standards.
So, reading between the lines, here's what I see:
The cable companies like competition the way the ILECs like CLECs. So, they tricked the CRTC into allowing a poison pill that they knew would run the competitive ISP afoul of ARIN IP addressing policy. ARIN is now asked to provide relief by altering its policies to moot the CRTC-level poison pill.
Is that about the size of it?
What about the layer 2 tunnelling described in John's links? Is the cable company required to provide both methods, the layer 2 tunnelling too? That doesn't require them to assign addresses to the cable company, right? What's the down side when an ISP elects to use the L2tunnelling method instead of the managed router method?
Thanks,
Bill Herrin
--
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list