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 <[email protected]>
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 <[email protected]>
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
<[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.
_______________________________________________
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 [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.
