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 <ch...@semihuman.com> wrote: > > > > > > > On May 23, 2024, at 19:17, Tyler O'Meara via ARIN-PPML > > > <arin-ppml@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@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 <i...@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@arin.net). > > > > > > Unsubscribe or manage your mailing list subscription at: > > > > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > > > > Please contact i...@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@arin.net). > > > > > Unsubscribe or manage your mailing list subscription at: > > > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > > > Please contact i...@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@arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact i...@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@arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact i...@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@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.