[arin-ppml] Draft Policy ARIN-2012-7: Reassignments for ThirdParty Internet Access (TPIA) over Cable

Hayee Bokhari bokhari at cronomagic.com
Thu Sep 6 15:51:27 EDT 2012


Being a TPIA in Quebec and have presence in most regions we are exactly facing the issue which Jean-Francois pointed out, A TPIA cannot suggest an Engineering change unless a complete flowchart of Network and IP assignment knowledge is provided to TPIA, in most cases TPIA works in dark, 

The issue is serious because at one point it will bring the TPIA expansion to a halt, while Jean-Francois has a valid point ARIN refuses to accept it as a valid, while assigning new IP's and the reason is that Cable operator is able to move IP blocks from low customer base area to high customer base area and ARIN knows this and TPIA is asked to first request the unusable blocked to be moved around and get used, which becomes catch 22 

Cogeco is holding back the TPIA expansion because of the same issue

Here is a solution or Gene in a box, cable operator should start using IPV6 across their Network, Is it possible, Yes. Can cable Operator do it????

Any comments Jean-Francois?

>arin-ppml-bounces at arin.net a écrit sur 06/09/2012 02:01:03 PM :
>
>> Joe Maimon <jmaimon at chl.com> 
>>
>> Does the technology inherently require this sort of unaccountability and 
>
>> is there any way to change that and is it worth accommodating and 
>enabling?
>
>As someone familiar with this environment, let me try to shed some light 
>on 
>the issue. I'm afraid it's not a short and simple explanation. 
>
>Canadian cable operators do indeed require third parties to provision all 
>the access equipment (CTMSes) in a given "region" with subnets roughly 
>equal
>in size to the largest number of clients on any equipment. The reason 
>behind 
>this is quite simple, the third party does not have a vision of which 
>equipment correspond to the street address of a specific potential client. 
>
>By the nature of the cable technology, such street address <-> equipement 
>relationship changes in the network almost on a daily basis. The IP 
>provisioning must therefore be blanketed across the region because a 
>specific equipment may see the clients moving at any time. 
>
>The alternate approach to this would be to 
>1) have the TPIA notify the operator each time a new client must be turned 
>
>on. The operator would then reprovision the CMTS IP ranges accordingly. 
>We're talking of a 7 to 10 days process here at least. Not acceptable. 
>2) The TPIA would run the risk of running out of addresses each time 
>the operator transfers Docsis domains between equipment, as there's 
>practically no way to predict how many TPIA clients are in a specific
>docsis/geographic domain. 
>
>Both of the above being undesirable, the CRTC introduced the concept
>of TPIA "region" to limit the problem. A TPIA may choose to be deployed
>only in specific pre-defined geographic regions, limiting the need to 
>provision equipement where no clients will ever be present. 
>
>Even with the regionalization, most TPIAs still end up with very small 
>numbers of clients spread across many equipments. Meeting ARIN's 
>utilization constraints is therefore very difficult for any TPIA, 
>especially when starting, because the distribution of clients over 
>the different IP domains tends to be fairly uneven.
>
>Here's a fictious example: a TPIA starts with a region containing 256
>IP domains. The largest number of clients in a single domain is 35, 
>but the average is only 18, for a total of 4600 clients. 
>It requires 256 /26 to put in the network. This is a /18 with an 
>utilization ratio of only 4600/65536 = 28%. 
>
>If anyone has a solution to this problem that doesn't involve 
>extensive operational subnet swapping, let's hear it! Otherwise, 
>a change in policy is probably required. 
>
>/JF
>
>
>_______________________________________________
>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