<div dir="ltr"><div><font size="2"><br></font></div><div><font size="2">Got a chance to watch the video presentation from ARIN 52 re: <span><span>ARIN-2023-2: /<span>26</span> initial IPv4 allocation for <span>IXPs</span> <br></span></span></font></div><div><font size="2"><span><span><br></span></span></font></div><div><font size="2"><span><span>Summary;</span></span></font></div><div><font size="2"><span><span><br></span></span></font></div><div><font size="2"><span><span>This proposal is in search of a problem. To answer the questions, no it's not worth it to develop this proposal. No, it's not worth defining the term IXP since we already did, it's more than two networks interconnecting for the purposes of s 4.10 which reached consensus a long time ago. PeeringDB uses that as well. So does OIX. And on the third queston we should instead ensure, like we are with 4.5 related 4.10 requests, that the addresses are going where they should go. Improve justification standards. I think we're good as is.<br></span></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>Tl;Dr.</span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>- providers filter this space</span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>Not that I can tell. I ran a script to ping the .1 of each prefix in the micro allocations list as a simple test and do a reverse lookup on the ones that answered. I contrasted the ones that answered to RIPE RIS and saw they were considered "widely visible". From running some of the worlds largest networks I don't recall ever filtering or considering filtering these allocations. I observed the very first one reachable and also observed another being used in a DSL pool by a LEC. The registration on the prefix was in 2001 so I assume JC probably can explain that or declare it the way it is sometimes with record keeping or creation of the initial policy including operating networks by mistake.<br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>There's nothing in policy that CI shouldn't or can't be routed. <br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>- abuse of the space<br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>Yep. For some odd reason though I see some CLEC's embedded in the space along with LEC's. There's probably an historic reason this happened. There are some defunct allocations being abused. There's also some unexplainable. Not as easy as saying "take it back".<br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>- predicting IXP viability</span></font></div><div><font size="2"><span><br></span></font></div><div>Value is in the eye of the beholder - or the communities that use the IXPs.</div><div><br></div><div><font size="2"><span>I was entertained by the map. If you understand how the Internet was built it's not surprising the MSAs displayed (AKA as "highest population cities' ') were the first long line and long haul fiber fiber hubs. And IXP hubs. This room probably already knew this. I think the point was more about success than explaining the ecosystem to the ecosystem builders. No doubt that IXPs can be more successful in large metros. It takes a lot more than population density and fast service take rates though. Explain Charlotte, NC not having a successful IXP? <br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>Here's my map which instead shows opportunity for improvement: </span></font><a href="https://pasteboard.co/IScxyQHTAzpY.png">https://pasteboard.co/IScxyQHTAzpY.png</a> shows distances from counties to reach the nearest IX (that code is credited to Jay Hanke at Southfront, the rest of the map code is mine) showing the top 100 MSA's. If you extrapolate this out to micropolitan areas there are hundreds more. Red to green, farthest to closest to nearest IXP.<br></div><div><br></div><div>Saying peer count is indicative of success is like measuring IXPs based on traffic. Unless you know what the traffic distribution is you can't see value. It's not atypical that one or two peers are responsible for vast amounts of traffic. It's also not atypical that the value of bits exchange is higher further away from the tier 1 cities. <br></div><div><br></div><div><font size="2"><span>- Torix doesn't route CI space</span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>Sorry Kevin. </span></font><a href="http://www.torix.ca">www.torix.ca</a> has address 206.108.0.85, Reverse DNS lookup for <a href="http://206.108.0.1">206.108.0.1</a>: <a href="http://514-cr01-tor1.ip.torix.ca">514-cr01-tor1.ip.torix.ca</a>, 8.0.108.206.in-addr.arpa domain name pointer <a href="http://po1-56.400-cr01-tor2.ip.torix.ca">po1-56.400-cr01-tor2.ip.torix.ca</a>, etc. It's not the peering LAN which is a /23 (with 234 peers/ports in use according to PeeringDB). I did notice it was advertised by a 32 bit ASN which made me recall from my time as Vice Chair of the Torix it was done for 32 bit ASN compatibility testing.JN will remember. While it's not the peering LAN it is a CI prefix. I honestly see no issue with this.</div><br><div><font size="2"><span>- three members doesn't meet community expectations</span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>We made the policy and it reached consensus so it is assumed it certainly does. <br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>- The only people supporting are current IXP operators and they're confused</span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span>Not at all. Who better to comment on a policy that would affect a segment of the infrastructure than the people who build it?</span></font></div><div><br></div><div><font size="2">- Renumbering isn't that bad</font></div><div><br></div><div><font size="2">IXPs may renumber, but that doesn't mean it's easy. Try being on the receiving end at a large CDN who has a mostly open peering policy. Far from painless and damaging performance wise.</font></div><br><div><font size="2">- Awards for the meeting</font></div><div><font size="2"><br></font></div><div><font size="2">Kevin had the best commentary. Owen had the best stage presence. <br></font></div><div><font size="2"><br></font></div><div><font size="2">Have a great weekend all,</font></div><div><font size="2"><br></font></div><div><font size="2">-M<</font></div><div><font size="2"><br></font></div><div><font size="2"><br></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span><br></span></font></div><br><div><font size="2"><span><br></span></font></div><div><font size="2"><span><br></span></font></div><div><font size="2"><span><br></span></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 22, 2023 at 2:31 PM owen--- via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div style="font-family:LucidaGrande;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Draft Policies:<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">* ARIN-2023-2: /26 initial IPv4 allocation for IXPs </span></div></div></blockquote><div><br></div>I strongly encourage the abandonment of this proposal. It is a solution looking for a problem and almost every major exchange operator and many minor ones has come out in opposition both here and in other regions where it has been proposed.</div><div><br></div><div><blockquote type="cite"><div style="font-family:LucidaGrande;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">* ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete Networks and the addition of new Section 2.18 Organizational Identifier (Org ID)</span></div></div></blockquote><div><br></div>I look forward to the revision of this proposal based on the comments from the PPM.</div><div><span style="font-family:Calibri,sans-serif;font-size:11pt"> </span><br></div><div><span style="font-family:Calibri,sans-serif;font-size:11pt">Owen</span></div><div><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><br></div>_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>