[arin-ppml] Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers

[John Santos]

On 7/16/2020 11:39 AM, Kat Hunter wrote:
[...]
> 4.2.3.6 Original Text:
> Under normal circumstances an ISP is required to determine the prefix size of 
> their reassignment to a downstream customer according to the guidelines set 
> forth in RFC 2050. Specifically, a downstream customer justifies their 
> reassignment by demonstrating they have an immediate requirement for 25% of 
> the IP addresses being assigned, and that they have a plan to utilize 50% of 
> their assignment within one year of its receipt. This policy allows a 
> downstream customer’s multihoming requirement to serve as justification for a 
> /24 reassignment from their upstream ISP, regardless of host requirements. 
> Downstream customers must provide contact information for all of their 
> upstream providers to the ISP from whom they are requesting a /24. The ISP 
> will then verify the customer’s multihoming requirement and may assign the 
> customer a /24, based on this policy. Customers may receive a /24 from only 
> one of their upstream providers under this policy without providing additional 
> justification. ISPs may demonstrate they have made an assignment to a 
> downstream customer under this policy by supplying ARIN with the information 
> they collected from the customer, as described above, or by identifying the AS 
> number of the customer. This information may be requested by ARIN staff when 
> reviewing an ISP’s utilization during their request for additional IP 
> addresses space.
>
New version of proposed 4.2.3.6 replacement:

> 4.3.2.6 New Text, replacing old:
> If a downstream customer has a requirement to multihome, that requirement 
> alone will serve as justification for a /24 allocation. Downstream customers 
> must provide contact information for all of their upstream providers to the 
> ISP from whom they are requesting a /24, and utilize BGP as the routing 
> protocol between the customer and the ISP. Customers may receive a /24 from 
> only one of their upstream providers under this policy without providing 
> additional justification. ISPs may demonstrate they have made an assignment to 
> a downstream customer under this policy by supplying ARIN with the information 
> they collected from the customer, as described above, or by identifying the AS 
> number of the customer.
>
> -Kat Hunter
> [...]
Older version of proposed 4.2.3.6:
>
>
>     4.2.3.6. Reassignments to Multihomed Downstream Customers
>
>     If a downstream customer has a requirement to multihome, that
>     requirement alone will serve as justification for a /24 allocation.
>     Downstream customers must provide contact information for all of their
>     upstream providers to the ISP from whom they are requesting a /24, and
>     utilize BGP as the routing protocol between the customer and the ISP.
>     Customers may receive a /24 from only one of their upstream providers
>     under this policy without providing additional justification. ISPs may
>     demonstrate they have made an assignment to a downstream customer under
>     this policy by supplying ARIN with the information they collected from
>     the customer, as described above, or by identifying the AS number of the
>     customer.
>
>     Timetable for implementation: Immediate
>
I haven't digested this proposal sufficiently to have an opinion one way or the 
other, but I do have a general and a specific question.  Doesn't ARIN attempt to 
avoid mandating particular network technologies in policy, so as not to impede 
technological advances?

I am particularly referring to BGP in both versions of the proposed new policy.  
Would it be better to develop wording that would suggest BGP until something 
better comes along, by not specifically refer to it in the policy text?  Or is 
BGP considered to be as good as it's ever going to get, at least for IPv4 routing?


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

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