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.

Reply via email to