[arin-ppml] Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation
Tyler O'Meara
arin at tyleromeara.com
Fri May 24 11:48:56 EDT 2024
I would be fine with using the term "layer 2" instead of specifically mentioning
Ethernet.
Tyler
On Fri, 2024-05-24 at 10:27 -0400, Ryan Woolley wrote:
> 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.
> _______________________________________________
> 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.
More information about the ARIN-PPML
mailing list