[arin-ppml] Draft Policy ARIN-2024-4: Internet Exchange Point Definition
Bill Woodcock
woody at pch.net
Sun May 26 12:08:33 EDT 2024
> On May 24, 2024, at 22:31, Owen DeLong <owen at delong.com> wrote:
>> On May 24, 2024, at 00:16, Bill Woodcock <woody at pch.net> wrote:
>>> On May 23, 2024, at 06:24, Martin Hannigan wrote:
>>> 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.
For new allocations, presumably. It would be good to avoid wording which would leave IXPs seeking approval for additional allocations or transfers unable to justify them because they’d used some of the allocation for crossconnects.
> 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.
Agreed. Any actual lab or teaching environment can be numbered out of 1918 space.
-Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240526/a302a409/attachment.sig>
More information about the ARIN-PPML
mailing list