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 <[email protected]>
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 <[email protected]>
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 ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please [email protected] if you experience any issues.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
