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

Mon Apr 22 02:04:15 EDT 2024

That´s not the point Bill. As per my last message, this wish or intent 
he talks about looks more a convenience to get this into a more flexible 
scenario and divert the propose of the pool to supply addresses and 
support the emergence of IXPs with allowing them to act as RIRs and 
supply addresses to third parties which have the ability to get them 
direcetlly from the RIR. If the problem is that there is no IP space 
left for them to do directly with the RIR this other way cannot be an 
easier way to turning this pool into something that has never thought 
for and divert its propose.

Addresses from this pool have always been meant to be used for IXP 
Infrastructure and for connecting members in the LAN.

Fernando

On 22/04/2024 02:56, Bill Woodcock 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> 
>>>> 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> 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 contactinfo 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/748280f5/attachment-0001.htm>