> On May 26, 2024, at 09:08, Bill Woodcock <[email protected]> wrote: > > > >> On May 24, 2024, at 22:31, Owen DeLong <[email protected]> wrote: >>> On May 24, 2024, at 00:16, Bill Woodcock <[email protected]> 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.
Intereseting… I had read the existing and my proposed wording as requiring that there be SOME physical infrastructure based fabric involved, not that everything be used exclusively on that. > >> 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. Yep. Owen _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
