[arin-ppml] Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation

Fri May 24 10:27:02 EDT 2024

Many of the largest IXPs are using some mechanism for encapsulating
Ethernet in other protocols, including VXLAN (Equinix, FL-IX, others, ref.
https://apix.asia/26/apix26-abhishek-eie.pdf ) and MPLS (DE-CIX, ref.
https://www.de-cix.net/en/about-de-cix/news/peering-lans-2-0-evpn-rollout-on-the-de-cix-apollon-platform
).

Encapsulation is sufficiently normalized that "ethernet switch fabric" is
widely understood to mean that the PDUs being transported on the IXP's
fabric on behalf of its customers are Ethernet, so I don't think there is a
real risk that the use of encapsulation in a "physically present ethernet
switch fabric" would cause an IXP to fall outside the policy in a way that
precludes the assignment of CII IP space.

Regarding "ethernet", this is a case where being as specific as possible is
helpful in keeping resources available where they're needed.  Virtual IXPs
are consumers, not providers, of CII.  "physically present ethernet switch
fabric" reflects the reality of the existing IXP environment and leaves
less room for creative interpretations/abuse.

RIPE uses "physical" and "layer 2" and "peering LAN" (which is arguably
technically limiting).  See https://www.ripe.net/publications/docs/ripe-730/

If we strike "ethernet", what's to stop anyone from saying their one router
that connects to three ASNs is IXP with a "shared peering fabric" which
needs CII space?

The language as proposed protects the future viability of a very
established and very successful model.  Let's not create a back door for
address space that could harm that model over a philosophical desire to be
protocol agnostic or future-proof.

Regards,
Ryan Woolley

On Thu, May 23, 2024 at 11:04 PM Chris Woodfield <chris at semihuman.com>
wrote:

>
>
> > On May 23, 2024, at 19:17, Tyler O'Meara via ARIN-PPML <
> arin-ppml at arin.net> wrote:
> >
> > I like Owen's proposed language. I think it strikes the right balance
> between
> > being restrictive enough to prevent purely virtual IXes (which are cool,
> but
> > shouldn't qualify under 4.4) while not being overly prescriptive on how
> IX
> > operators need to design and run their IXes.
> >
> > As a point of discussion, if an IX used VXLAN for the peering LAN to
> connect
> > multiple DCs in the same metro area (using some kind of non-Internet
> connection
> > (DF, wave, etc) as the underlay), would this be an IX we want to be
> eligible
> > under 4.4? My opinion is yes, this is a "real" IX that should qualify
> (assuming
> > it meets the other requirements).
> >
>
> Your point of discussion is not theoretical - I’m aware at least two major
> IXes utilizing VXLAN today, albeit running on their own physical switches
> (and yes, over physical ethernet ports). Would this fit the description of
> the “virtual IX” that the authors state should not qualify for CII
> resources under this proposal? I don’t think that’s intended, but we should
> make sure this is clear.
>
>
> > Tyler
> >
> > On Thu, 2024-05-23 at 21:54 -0400, Martin Hannigan wrote:
> >>
> >>
> >> On Thu, May 23, 2024 at 21:31 Owen DeLong via ARIN-PPML <
> arin-ppml at arin.net>
> >> wrote:
> >>> I support the spirit of the draft policy, but I’d like to see a change
> that
> >>> I don’t think will be controversial…
> >>>
> >>> 1. ARIN should not be specifying network technologies. “A physically
> present
> >>> ethernet switch” is way too specific for NRPM IMHO. I would propose,
> >>> instead, that we specify “connected to a shared peering fabric via
> physical
> >>> infrastructure (e.g. a shared ethernet switch).”
> >>>
> >>> In the past, we have had internet exchanges that were (e.g.) ATM based
> and
> >>> had multiple physical switches spread over a variety of locations. I
> don’t
> >>> know that there are currently any non-ethernet based exchanges still in
> >>> operation, but I also don’t know what kind of networking technology
> might
> >>> occur next week. For example, I think it would be perfectly valid to
> set up
> >>> an infiniband exchange if there were enough interested participants,
> but
> >>> under this proposed policy, that would not be allowed.
> >>>
> >>> Owen
> >>>
> >>
> >>
> >>
> >>>
> >>>
> >>
> >>
> >> Thanks Owen.
> >>
> >> I’m one of four authors.  And many interested. Speaking for myself.
> >>
> >> The reason its specific is to address specific issues.
> >>
> >> Virtual IX’s may be able to justify 4.4 resources and applying the
> hardware
> >> test tries to prevent that. Many may claim Virtual IX are educational in
> >> nature. This is good. However, they are not CI as a result and not in
> need of
> >> precious 4.4 resources.
> >>
> >> The other is IX preparing and certifying peers, getting resources but
> then
> >> never deploying a switch fabric. Wanted to have a good revocation
> trigger.
> >> Likely to be used rarely if ever, but for thoroughness.
> >>
> >> Neither are corner cases.
> >>
> >> On the switch tech l2 piece ATM etc does contradict demonstrated
> standards.
> >> And if IX tech changes, policy could be changed. If someone tells ARIN
> they’re
> >> deploying an ATM switch as an IX in 2024 it should set off alarm bells
> IMHO.
> >>
> >> As long as the physical switch component is kept I don't think there
> would be
> >> heartache. But hope the reasons help everyone understand the inside
> baseball.
> >>
> >>
> >>>
> >>>
> >>>> On May 21, 2024, at 09:26, ARIN <info at arin.net> wrote:
> >>>>
> >>>> On 16 May 2024, the ARIN Advisory Council (AC) accepted
> “ARIN-prop-333:
> >>>> Rewrite of NRPM Section 4.4 Micro-Allocation” as a Draft Policy.
> >>>>
> >>>> Draft Policy ARIN-2024-5 is below and can be found at:
> >>>>
> >>>> https://www.arin.net/participate/policy/drafts/2024_5
> >>>>
> >>>> You are encouraged to discuss all Draft Policies on PPML. The AC will
> >>>> evaluate the discussion to assess the conformance of this draft policy
> >>>> with ARIN's Principles of Internet number resource policy as stated
> in the
> >>>> Policy Development Process (PDP). Specifically, these principles are:
> >>>>
> >>>> * Enabling Fair and Impartial Number Resource Administration
> >>>> * Technically Sound
> >>>> * Supported by the Community
> >>>>
> >>>> 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)
> >>>>
> >>>>
> >>>> Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation
> >>>>
> >>>> Problem Statement:
> >>>>
> >>>> The current NRPM Section 4.4 language hasn’t aged well. As the ARIN 53
> >>>> policy experience report demonstrated, 4.4 has also become difficult
> to
> >>>> implement by ARIN staff. Growth and use of Internet Exchanges has also
> >>>> changed. The overhaul seeks to improve technical soundness, respect
> the
> >>>> privilege of a dedicated pool and to more closely observe conservation
> >>>> principles using clear, minimum and enforceable requirements and
> >>>> underscoring the value of routability of assigned prefixes as
> required.
> >>>>
> >>>> ARIN 4.4 CI Assignments
> >>>>
> >>>> The intent of this policy is not to unreasonably preclude the use of
> an
> >>>> allocated or assigned prefix in servicing the needs of critical
> >>>> infrastructure of the Internet.
> >>>>
> >>>> ARIN will reserve a /15 equivalent of IPv4 address space for Critical
> >>>> Infrastructure (CI) of the Internet within the ARIN RIR service area.
> >>>> Assignments from this pool will be no smaller than a /24. Sparse
> >>>> allocation will be used whenever practical. CI includes Internet
> >>>> Exchanges, IANA authorized root servers, ccTLD operators, ARIN, and
> IANA.
> >>>> Addresses assigned from this pool may be revoked if no longer in use
> or
> >>>> not used for approved purposes. Only Section 8.2 transfers are
> allowed.
> >>>> Use of this policy for CI is voluntary. ARIN will publish all 4.4
> >>>> allocated addresses for research purposes.
> >>>>
> >>>> 4.4.1 Internet Exchange Assignments
> >>>>
> >>>> • Internet Exchange operators must justify their need by providing the
> >>>> following:
> >>>>
> >>>> • A minimum of three initial participants connected to a physically
> >>>> present ethernet switch fabric to be used for the purpose of Internet
> >>>> Exchange facilitated peering
> >>>>
> >>>> • Justification must include:
> >>>>        - Three unique participant names and ASNs not under common
> control
> >>>>        - Direct contact information for each participant
> >>>>
> >>>> • Staff can reasonably validate hardware existence and participants
> intent
> >>>>
> >>>> • Applicant Internet Exchange affiliated ASNs are not eligible to be
> >>>> included in meeting the participant requirement
> >>>>
> >>>> • Assigned addresses may be publicly reachable at the operators
> discretion
> >>>> and be used to operate all of the Internet Exchange's infrastructure
> >>>>
> >>>> 4.4.2 Root and ccTLD Assignments
> >>>>
> >>>> Root and ccTLD operators will provide justification of their need and
> >>>> certification of their status as currently active zone operators.
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240524/20c91b5d/attachment-0001.htm>