[arin-ppml] Advisory Council Meeting Results - November 2023
David Farmer
farmer at umn.edu
Mon Dec 18 16:06:28 EST 2023
On Mon, Dec 18, 2023 at 2:34 PM Owen DeLong via ARIN-PPML <
arin-ppml at arin.net> wrote:
>
>
> > On Dec 18, 2023, at 11:28, 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.
>
> My point is don’t shrink it, let it roll at /24 until it runs out. Once it
> does, IXPs are the least disadvantaged by this fact of virtually any
> network users because (in theory) an IXP language is used only to exchange
> routing information and forward traffic. Since BGP fully supports
> deliverability of IPv4 NLRI over IPv6 peering sessions and IPv4 packets can
> be subsequently delivered without requiring IPv4 on the router interfaces
> on the IXP, despite traditional mindset, there’s no technical or
> engineering reason why an IXP actually needs IPv4 to facilitate IPv4
> traffic exchange.
>
> So instead of shrinking prefixes now and extending the life of the pool
> with no predictable benefit to the community, I favor continuing to
> allocate /24s to IXPs until they run out and then encouraging future IXPs
> to either engage the transfer market or deliver IPv4 NLRI over IPv6.
>
I'll also note that unlike RIPE or any other RIRs, we already have section
4.1.7 Reserved Pool Replenishment. So, as the reserved pools are running
out, any returned resources will go to replenishing them instead of the
waiting list. Furthermore, we have something like 7 years or so in the
current 4.4 reserved pool, at least based on current allocation rates. So,
we have already implemented another "better" option, at least in my opinion.
Realize it is impossible to extend the runway for IPv4 indefinitely. So, I
think it is time to start singing the popular '50s song, "Que Sera, Sera."
https://en.wikipedia.org/wiki/Que_Sera,_Sera_(Whatever_Will_Be,_Will_Be)
> Owen
>
> >
> > 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.
>
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20231218/3c087102/attachment.htm>
More information about the ARIN-PPML
mailing list