[arin-ppml] Draft Policy ARIN-2024-4: Internet Exchange Point Definition

[Owen DeLong]

> On May 24, 2024, at 00:16, Bill Woodcock <woody at pch.net> wrote:
> 
>> On May 23, 2024, at 06:24, Martin Hannigan  wrote:
>>> On Wed, May 22, 2024 at 5:07 PM Tyler O'Meara wrote:
>>> 1) We should only include abbreviations/other names for the term if they’re actually used in the NRPM; I think future text that uses this definition would be clearer if we selected a single acronym.
>> But that's not the way the real world works. All the acronyms are in use unfortunately.
> 
> I agree with Marty on this.  The point of listing the names and acronyms is to avoid confusion…  “I’m trying to start an Internet Exchange…  does this policy apply to me, or does it only apply to ‘Internet exchange points?’”  List them all, but lead with the one that’s being defined for use in ARIN policies.  The others are being explicitly called out as synonyms for the avoidance of confusion.  An ARIN policy document isn’t going to change common usage, so that’s a non-goal.
> 
>> On May 24, 2024, at 03:41, Owen DeLong via ARIN-PPML <arin-ppml at arin.net> wrote:
>>> On May 22, 2024, at 21:24, Martin Hannigan <hannigan at gmail.com> wrote:
>>>> On May 22, 2024, at 23:07, Tyler O'Meara via ARIN-PPML <arin-ppml at arin.net> wrote:
>>>> I would remove the reference to Ethernet (or provide it as an example); we
>>>> shouldn't prescribe what L2 switching technology gets used by the IXP
>>> Open IX OIX-1, an ANSI standard, prescribes ethernet for IX's
>> IMHO, Open IX OIX-1 is in error here. I think that prescribing a specific transport technology is flawed.
> 
> I agree with Tyler and Owen on this.  There have been many IXPs which use other layer-2 protocols than Ethernet, and there exist quite a few right now today which use other layer-2 protocols internally, even if they present Ethernet ports to participants.  Over-prescriptivity is the bane of good policy.
> 
>> I agree that it should be a shared segment fabric
> 
> I’m on the fence about this.  At first glance, yeah, that seems obvious.  But then what about all the crossconnects and VLAN-based “virtual crossconnects?”  Those all _necessarily_ need to be numbered out of provider space?  I agree that at large exchanges, that would consume a lot of IP space quickly, but it’s not like it’s not getting consumed anyway, it’s just a question of who provides it.  If the IX provides it, the peering connection is obvious in traceroutes and to other analytical tools, and that’s very valuable.  If one of the participants provides it, that information is lost and has to be fuzzily inferred.

Every IX implementation I’m aware of that uses those still has some form of shared fabric at the core of the exchange which I think would still qualify with the proposed wording.

What we are working to avoid here is permitting “virtual IX” implementations, which are great for teaching, but don’t represent real world peering interconnects in any meaningful way.

Owen