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

Mon Apr 22 19:43:57 EDT 2024

On 22/04/2024 20:35, Chris Malayter wrote:
> I certainly didn’t get that vibe from Owen.
>
> However, Fernando, your recommendation is a policy change.  I would be 
> against that at this point.
>
> I firmly believe that IX’s should be able to use a /24 for services 
> and additional 4.4 space for their IX LAN.
Hi Chris. In which of my previous messages Am I saying otherwise ?
Regards

>
> There is zero in the current iteration of the policy to prohibit this.
>
> -Chris
>
>
>> On Apr 22, 2024, at 6:49 PM, Fernando Frediani <fhfrediani at gmail.com> 
>> wrote:
>>
>> Of course Owen, on every email I read from you I get the impression 
>> that if it was up to you there would be no need for RIRs and policies 
>> to exist or maybe to be conservative in this impression you seem to 
>> like of the RIRs as a simple bookeeper with no power to enforce 
>> anything, even what the community who develops the policies set as 
>> reasonable.
>>
>> It is of course up to the RIR, has always been and hopefully will 
>> continue to be, to dictate certain things which some private ones 
>> keeps refusing to comply because take out their freedom to do what 
>> they like with something doesn't belong to them. Simply if something 
>> is not in line with a policy set by this forum it is up to the RIR to 
>> dictate something that may not be desired by someone. I know that it 
>> may not be good for certain kind of business but life is not fair in 
>> many ways. So, just save up from recurring to this old useless mantra.
>>
>> It doesn't matter if an IXP have abused or not. What I am putting is 
>> there should be well defined rules on how resources can be used and 
>> not allow this continuous "rule-less party desire" go just because it 
>> may hit someone's desire to take advantage of the system.
>> Fernando
>>
>> On 22/04/2024 16:57, Owen DeLong wrote:
>>> I’m not the one who is mixed up here. I know exactly what the policy 
>>> intent was, I was very involved in creating the policy.
>>>
>>> IXPs are meant to provide value to the peers which gather at the IXP 
>>> by facilitating the efficient delivery of traffic amongst 
>>> participants in the IXP. One way to do that is direct peering 
>>> relationships through the IXP fabric. However, that is not the only 
>>> valid mechanism for doing so. Additional services such as route 
>>> servers, caches, etc. can also bring value to participants and it is 
>>> not the role of the RIRs to dictate to IXPs which of those 
>>> particular things are or are not valid use of the IXPs addressing.
>>>
>>> My point is that I do not know of any IXPs currently abusing their 
>>> addresses for any of the purposes you stated would occur.
>>>
>>> I’m not supporting or proposing any change to current IXP related 
>>> policy. I’m stating that the policy is sufficient as is.
>>>
>>> You are the one arguing for a change. That change is not, IMHO, 
>>> supported by the record and multiple other people have commented on 
>>> the potential harmful effects of a change.
>>>
>>> As such, I fail to see how you can claim I am arguing for a more 
>>> flexible scenario. I. am arguing to preserve the status quo.
>>>
>>> Owen
>>>
>>>
>>>> On Apr 21, 2024, at 22:45, 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.
>>>
>> _______________________________________________
>> 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 contactinfo 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/f98248d4/attachment-0001.htm>