[arin-ppml] Advisory Council Meeting Results - November 2023
Aaron Wendel
aaron at wholesaleinternet.net
Tue Dec 19 13:50:54 EST 2023
Has anyone bothered to ask the IXP operators what they think?
Aaron
On 12/19/2023 12:45 PM, Fernando Frediani wrote:
> Hello there Matthew
>
> That's actually a very good point and question. In general I would say
> Exchange point operators, even commercial ones who still play an
> important role on Internet ecosystem development. In the other hand
> public Internet Exchange Points with more transparent policy of who
> can apply should be best regarded above the previous one.
> I guess the main point to look at who predictable would be this
> reserve if both type of entities would request, what is the cost for
> the RIR to to supervise its usage and all the stuff involved.
> If there are concerns about how much this type of assignments can be
> made of course I would say to restrict to public Internet Exchange
> Points with more open and transparent policies or with no commercial
> interest.
>
> Fernando
>
> On 18/12/2023 17:03, Matthew Wilder wrote:
>> Fernando,
>>
>> Indeed I think there is a great deal of public support for IXPs to be
>> able to continue to be an important part of the landscape. We as
>> shepherds of ARIN-2023-2 are considering all of the feedback we are
>> seeing on PPML.
>>
>> I just wish to clarify, by IXP do you mean a public Internet Exchange
>> Point which is more or less transparent about its list of peers and
>> how new peers can apply to connect regardless of other direct
>> business relationships? Or do you mean the "Exchange point operators"
>> - a term which is not defined in NRPM - which can currently qualify
>> for a /24 prefix with only 3 peering participants (which may or may
>> not be in business together) and without necessarily any degree of
>> transparency?
>>
>> Thanks,
>> Matthew Wilder
>>
>>
>> On Mon, Dec 18, 2023 at 11:29 AM Fernando Frediani
>> <fhfrediani at gmail.com> wrote:
>>
>> I think it is forcing too much for so little. Just give the IPv4
>> IXPs
>> need to operate and make people`s life easier. IXPs are a very
>> important
>> part of Internet ecosystem that changes a lot of things for
>> better in
>> terms of redundancy, robustness and performance. Yes IPv4 NLRI
>> over IPv6
>> may work but people don't seem to be willing to use it very much
>> and for
>> such usage for small chunks it makes it worth.
>> Just make in a way that is possible and easy for the RIR to know
>> if one
>> if misusing it for other proposes and be able to action.
>>
>> I also don't like the idea of shrinking IPv4 delegations form RIRs
>> below
>> /24, but if that is the feasible option than better than nothing.
>>
>> Fernando
>>
>> On 25/11/2023 22:33, owen--- via ARIN-PPML wrote:
>> > The problem I have with this line of thinking is that in
>> reality, IXPs
>> > are the place with the least need for an IPv4 prefix.
>> >
>> > It’s dirt simple to pass along IPv4 NLRI over an IPv6 peering
>> session
>> > these days, even if you’re not doing IPv6 anywhere else in your
>> network.
>> >
>> > The only real consequence of this is to make IPv4 trace routes
>> look a
>> > little funky on the hop that traverses the exchange.
>> >
>> > Yes, there’s a perceptual hurdle to this and there are those
>> that view
>> > an IPv6 only IXP as undesirable compared to a dual-stack one,
>> but at
>> > some point, we’re going to just have to get over that.
>> >
>> > I don’t support shrinking IPv4 delegations from RIRs below /24 and
>> > multiple IXPs have argued against doing so.
>> >
>> > The only possible gain to this policy is prolonging the
>> perceived life
>> > of IPv4 which, IMHO, is a step away from good. (Note, it won’t
>> prolong
>> > the actual life of IPv4, just increase the amount of pain involved
>> > while it lasts).
>> >
>> > Owen
>> >
>> >
>> >> On Nov 25, 2023, at 16:55, Martin Hannigan <hannigan at gmail.com>
>> wrote:
>> >>
>> >>
>> >> Went back to work on language that may have an impact. We seem to
>> >> have dropped three paragraphs from drafts that are in the current
>> >> policy. I can't tell if it's intentional but I'll assume it was.
>> >> Doesn't appear clearly marked for deletion unless I missed it.
>> The
>> >> original or the June edit was also not a mirror of the RIPE
>> proposal.
>> >> ARIN can decide if anything needs to be fixed documentation
>> wise or
>> >> if we could use the help of a red line for the below. Didn't
>> matter
>> >> much anyhow.
>> >>
>> >> The easiest way to extend the life of the micro allocation pool
>> will
>> >> be to apply better justification standards. Right now, 26% of
>> US IXPs
>> >> don't meet the minimum criteria for an initial /24 using the
>> existing
>> >> policy. Most of that happened in the last few years and as Aaron
>> >> Wendell discussed at the last meeting.
>> >>
>> >> Here's what I support
>> >>
>> >> - Initial allocation of a /26 to a new IXP, and
>> >> - Include "CI" to keep it simple and consistent. No reason to
>> single
>> >> out IXPs
>> >> - A voluntary global routability requirement determined by
>> applicant
>> >> for CI
>> >> - Tightened utilization requirements for CI
>> >> - Removing the possibility of other RIR's asking ARIN for
>> allocations
>> >> (glitch?)
>> >>
>> >> If the root or a TLD can't do it, what makes anyone think an
>> IXP can?
>> >>
>> >> I agree with my RIPE friends' comments regarding up front
>> costs. It
>> >> already costs $11,000 for a "free" IXP without a /24. Add a
>> transfer
>> >> /24 and it's $22,000 not including opex, RIR fees,
>> depreciation, etc.
>> >> If it does cost a future IXP an additional $11,000 for a /24
>> and it's
>> >> not easily absorbed (lots of that happening today) they failed
>> and
>> >> will not start up. Turning the knobs on network economics
>> should go
>> >> slow - as they also acknowledged. And should als be applied to
>> non-CI
>> >> first. That seems like a faster way to enable better transition.
>> >>
>> >> On a last note. It would be nice to have a "style sheet" so we
>> had
>> >> consistency with defined terms and language. Repeating "under
>> this
>> >> section" and other "time honored traditions" makes policy hard to
>> >> read when it doesn't have to be.
>> >>
>> >> 4.4 Micro-allocation
>> >>
>> >> ARIN will make IPv4 micro-allocations to critical infrastructure
>> >> (“CI”) providers of the Internet, which includes Internet
>> Exchange
>> >> Points (“IXP”), IANA authorized root servers, top-level domain
>> >> operators and this RIR. Requests for IPv4 allocations will be no
>> >> smaller than a /26 or larger than a /23 for allocations which
>> require
>> >> global reachability. Global reachability requirements will be
>> >> determined by the requestor. ARIN will maintain a previously
>> reserved
>> >> /15 of IPv4 address space for the purposes of CI allocations.
>> >>
>> >> 4.4.1 Additional Requirement for IXPs
>> >>
>> >> An IXP requesting an initial IPv4 allocation from the blocks
>> >> specifically reserved for this purpose will initially be
>> assigned a
>> >> /26 allocated from a /24 by default if they demonstrate three
>> >> independent ASN’s are planning to interconnect on the IXP fabric
>> >> using the requested allocation. An IXP requesting an allocation
>> >> larger than a /24 must show their plan to utilize more than
>> 50% of
>> >> the requested allocation size up to a /23. Allocations larger
>> than a
>> >> /23 will be considered on a case-by-case basis using usual and
>> >> customary allocation practices in effect at the time of the
>> request.
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Nov 21, 2023 at 12:34 PM ARIN <info at arin.net> wrote:
>> >>
>> >> In accordance with the Policy Development Process (PDP), the
>> >> Advisory Council met on 16 November 2023.
>> >>
>> >> The AC has advanced the following to Draft Policy status
>> (will be
>> >> posted separately for discussion):
>> >>
>> >> * ARIN-prop-327: Reduce 4.18 maximum allocation
>> >>
>> >> The AC advances Proposals to Draft Policy status once they
>> are
>> >> found to be within the scope of the Policy Development
>> Process
>> >> (PDP) and contain a clear problem statement.
>> >>
>> >> The AC has advanced the following to Recommended Draft Policy
>> >> status (will be posted separately for discussion):
>> >>
>> >> * ARIN-2023-1: Retire 4.2.1.4. Slow Start
>> >>
>> >> The AC advances Draft Policies to Recommended Draft Policy
>> status
>> >> once they have been fully developed and meet ARIN's
>> Principles of
>> >> Internet Number Resource Policy. Specifically, these
>> principles are:
>> >>
>> >> * Enabling Fair and Impartial Number Resource Administration
>> >>
>> >> * Technically Sound
>> >>
>> >> * Supported by the Community
>> >>
>> >> The AC is continuing to work on:
>> >>
>> >> Draft Policies:
>> >>
>> >> * ARIN-2022-12: Direct Assignment Language Update
>> >>
>> >> * ARIN-2023-2: /26 initial IPv4 allocation for IXPs
>> >>
>> >> * ARIN-2023-4: Modernization of Registration Requirements
>> >>
>> >> * ARIN-2023-6: ARIN Waitlist Qualification
>> >>
>> >> * ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11
>> >> Multiple Discrete Networks and the addition of new Section
>> 2.18
>> >> Organizational Identifier (Org ID)
>> >>
>> >> Recommended Draft Policies:
>> >>
>> >> * ARIN-2023-5: Clean-up of NRPM Sections 4.3.4, 4.4, 4.10
>> and 6.10.1
>> >>
>> >> The PDP can be found at:
>> >>
>> >> https://www.arin.net/participate/policy/pdp/
>> >>
>> >> Draft Policies and Proposals under discussion can be found
>> at:
>> >>
>> >> https://www.arin.net/participate/policy/drafts/
>> >>
>> >> Regards,
>> >>
>> >> Eddie Diego
>> >>
>> >> Policy Analyst
>> >>
>> >> American Registry for Internet Numbers (ARIN)
>> >>
>> >> _______________________________________________
>> >> ARIN-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:
>> >> https://lists.arin.net/mailman/listinfo/arin-ppml
>> >> Please contact info at arin.net if you experience any issues.
>> >>
>> >> _______________________________________________
>> >> ARIN-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:
>> >> https://lists.arin.net/mailman/listinfo/arin-ppml
>> >> Please contact info at arin.net if you experience any issues.
>> >
>> >
>> > _______________________________________________
>> > ARIN-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:
>> > https://lists.arin.net/mailman/listinfo/arin-ppml
>> > Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> ARIN-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:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
> _______________________________________________
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
--
================================================================
Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
http://www.wholesaleinternet.com
aaron at wholesaleinternet.com
================================================================
More information about the ARIN-PPML
mailing list