In general, I agree with your point. Perhaps “Customer must originate 
prefix(es) and announce them via a border routing protocol (e.g. BGP-4) to each 
of their upstreams."

In specific, I think it’s extremely unlikely that there will be any significant 
advances or changes in IPv4 routing protocols as the IETF has pretty thoroughly 
expressed a
desire to stop working on IPv4 except in furtherance of transition to IPv6.

Owen


> On Jul 16, 2020, at 11:06 , John Santos <[email protected]> wrote:
> 
> 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
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to