<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 22/04/2024 20:35, Chris Malayter
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:950DC60C-5BCC-453F-8AA5-C8B636933949@terahertz.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
I certainly didn’t get that vibe from Owen.
<div><br>
</div>
<div>However, Fernando, your recommendation is a policy change. I
would be against that at this point.</div>
<div><br>
</div>
<div>I firmly believe that IX’s should be able to use a /24 for
services and additional 4.4 space for their IX LAN.</div>
</blockquote>
Hi Chris. In which of my previous messages Am I saying otherwise ? <br>
Regards<br>
<br>
<blockquote type="cite"
cite="mid:950DC60C-5BCC-453F-8AA5-C8B636933949@terahertz.net">
<div><br>
</div>
<div>There is zero in the current iteration of the policy to
prohibit this.</div>
<div><br>
</div>
<div>-Chris</div>
<div><br>
</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Apr 22, 2024, at 6:49 PM, Fernando Frediani
<a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 22/04/2024 16:57, Owen
DeLong wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7C3F0B16-A310-4024-A7ED-D6589C6BE943@delong.com">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
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.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>My point is that I do not know of any IXPs
currently abusing their addresses for any of the
purposes you stated would occur.</div>
<div><br>
</div>
<div>I’m not supporting or proposing any change to
current IXP related policy. I’m stating that the
policy is sufficient as is.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Owen</div>
<div><br id="lineBreakAtBeginningOfMessage">
<div style="font-size: 17px;"><br>
<blockquote type="cite">
<div>On Apr 21, 2024, at 22:45, Fernando
Frediani <a class="moz-txt-link-rfc2396E"
href="mailto:fhfrediani@gmail.com"
moz-do-not-send="true"><fhfrediani@gmail.com></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<p>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.<br>
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.</p>
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 22/04/2024
00:06, Owen DeLong wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CB7C4F6F-3950-423A-AED2-8E66B96FBC24@delong.com">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
A small probability of abuse is generally
not seen as a reason to deny legitimate
users.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Owen</div>
<div><br
id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Apr 18, 2024, at 22:31,
Fernando Frediani <a
class="moz-txt-link-rfc2396E"
href="mailto:fhfrediani@gmail.com" moz-do-not-send="true"><fhfrediani@gmail.com></a>
wrote:</div>
<br
class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<p>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.<br>
</p>
<p>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 ?<br>
They and any other IX member,
regardless of their business,
can get their own allocations
with their own resources.</p>
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On
19/04/2024 02:13, Owen DeLong
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3EBCE08A-0CFF-48C4-AA4B-E48CEC34CB0F@delong.com">
<meta
http-equiv="content-type"
content="text/html; charset=UTF-8">
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.
<div><br>
</div>
<div>Owen</div>
<div><br
id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Apr 18, 2024, at
20:35, Fernando
Frediani <a
class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"
moz-do-not-send="true"><fhfrediani@gmail.com></a> wrote:</div>
<br
class="Apple-interchange-newline">
<div>
<meta
http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>
<div
class="moz-cite-prefix">On 18/04/2024 21:34, Matt Peterson wrote:<br>
</div>
<blockquote
type="cite"
cite="mid:CAFN0R254BiNoLf6SzALG7-i_Xurcw6yWkPX-0L25zPRksK_cUw@mail.gmail.com">
<meta
http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><clip>
<div><br>
</div>
<div>If the
policy needs
revision <i>(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),
</i>maybe
consider
micro-allocations
for IXP usage
as unannounced
prefixes and
for routed
prefixes, an
IXP applies
under NRPM 4.3
<i>(end user
assignments).
<br>
</i></div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>Regards<br>
Fernando<br>
</p>
<blockquote
type="cite"
cite="mid:CAFN0R254BiNoLf6SzALG7-i_Xurcw6yWkPX-0L25zPRksK_cUw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>--Matt</div>
</div>
<br>
<fieldset
class="moz-mime-attachment-header"></fieldset>
<pre
class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext"
href="https://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this
message because you
are subscribed to<br>
the ARIN Public Policy
Mailing List (<a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage
your mailing list
subscription at:<br>
<a
class="moz-txt-link-freetext"
href="https://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a> if
you experience any
issues.<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message
because you are subscribed to<br>
the ARIN Public Policy Mailing
List (<a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:ARIN-PPML@arin.net"
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing
list subscription at:<br>
<a class="moz-txt-link-freetext"
href="https://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:info@arin.net"
moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are
subscribed to<br>
the ARIN Public Policy Mailing List (<a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:ARIN-PPML@arin.net"
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list
subscription at:<br>
<a class="moz-txt-link-freetext"
href="https://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:info@arin.net"
moz-do-not-send="true">info@arin.net</a> if
you experience any issues.<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed
to<br>
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</body>
</html>