[arin-ppml] Feedback on ARIN 53 question on micro-allocations for IXPs

[Martin Hannigan]

Agree.  We (US IX operators) are tight knit and self police to an extent.
We know whats up with 4.4 prefixes. We’ve also spoken with staff
occasionally about questions they have re: IX. It’s a good relationship
overall.

RS standards could be tightened a little, but thats all I cant think of
besides modernizing 4.4 which I heard there may be a proposal forthcoming.

HTH

-M<



.


Woodcock <woody at pch.net> wrote:

> Fernando: Owen is correct, the type of abuse you’re hypothesizing has not,
> in fact, occurred, in 32 years of IXPs.
>
> Since you’re the one proposing to impose a cost on everyone else, the
> burden falls on you to prove that is solves an actual problem, not on Owen
> to prove that it does not.
>
>                 -Bill
>
>
> On Apr 22, 2024, at 7:44 AM, Fernando Frediani <fhfrediani at gmail.com>
> wrote:
>
> 
>
> It seems you kind of disregards the basics of IP assignment and mix up
> things and what they were made for and thought for. It is not because
> something looks convenient, that is something right. When conveniences
> prevail over the main point we start to miss the discussion propose. What
> you are saying below looks more a personal preference if you were in charge
> of an IX to make it develop than what is the main point of the discussion
> how resources from a special pool should be treated.
> IXPs are not Broadband Services Providers nor RIRs and are not meant to
> distribute IP space to anyone. IXPs need the IPs to build its core services
> in order to interconnect ASNs locally. Organizations connecting to an IXP
> have the ability to go directly to the RIR and get resources from there
> through different ways and that's how it should continue.
>
> Fernando
> On 22/04/2024 00:06, Owen DeLong wrote:
>
> A small probability of abuse is generally not seen as a reason to deny
> legitimate users.
>
> I think we can generally count on IXPs not to distribute large portions of
> their resources to cache providers that do not bring significant value to
> the users of the IX with those resources. To the best of my knowledge,
> there is no problem of abuse to date. As such, I think your concern here
> has about as much credibility as those crying about election fraud in the
> US.
>
> Owen
>
>
> On Apr 18, 2024, at 22:31, Fernando Frediani <fhfrediani at gmail.com>
> <fhfrediani at gmail.com> wrote:
>
> By doing this it creates a short path to some specific type of Internet
> companies over the others to have access to scarce resources via someone
> else's right (the IX) to request those addresses for the minimum necessary
> to setup an IX, not to 'give a hand' to third parties. It would start to
> distort the purpose of the pool.
>
> Content providers members are members like any other connected to that IX.
> Why make them special to use these resources if other members (e.g:
> Broadband Internet Service Providers) connected to that same IX cannot have
> the same privilege ?
> They and any other IX member, regardless of their business, can get their
> own allocations with their own resources.
>
> Fernando
> On 19/04/2024 02:13, Owen DeLong wrote:
>
> I think that if it’s a cache that is serving the IX (i.e. the IX member
> networks) over the IX peering VLAN, that’s perfectly valid.
>
> Owen
>
>
> On Apr 18, 2024, at 20:35, Fernando Frediani <fhfrediani at gmail.com>
> <fhfrediani at gmail.com> wrote:
>
> On 18/04/2024 21:34, Matt Peterson wrote:
>
> <clip>
>
> If the policy needs revision *(John's comments did not provide enough of
> a background story - it's unclear if this a yet another IPv4 land grab
> approach, and/or IXP's evolving into hosting content caches, and/or the
> historical industry acceptable usage that Ryan shares), *maybe consider
> micro-allocations for IXP usage as unannounced prefixes and for routed
> prefixes, an IXP applies under NRPM 4.3
> *(end user assignments). *
>
> I have a similar conversation recently with someone willing to use IXP
> allocations to assign to content caches and on this point I think that IXP
> pool should not be for that. Even knowing the positive impact a hosted
> content directly connected to a IXP makes it is their business to being
> their own IP address not the IXP and to be fair if you think of any CDN
> service they all have total means to do that. Therefore IXP allocations
> should be used for IXP own usage, so internal Infrastructure and to connect
> members and things should not be mixed up.
>
> Regards
> Fernando
>
>
> --Matt
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240422/dd70eda5/attachment-0001.htm>