[arin-ppml] Advisory Council Meeting Results - November 2023

Fri Dec 8 20:36:22 EST 2023

Got a chance to watch the video presentation from ARIN 52 re: ARIN-2023-2: /
26 initial IPv4 allocation for IXPs

Summary;

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.

Tl;Dr.

- providers filter this space

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.

There's nothing in policy that CI shouldn't or can't be routed.

- abuse of the space

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".

- predicting IXP viability

Value is in the eye of the beholder - or the communities that use the IXPs.

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?

Here's my map which instead shows opportunity for improvement:
https://pasteboard.co/IScxyQHTAzpY.png 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.

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.

- Torix doesn't route CI space

Sorry Kevin. www.torix.ca has address 206.108.0.85, Reverse DNS lookup for
206.108.0.1: 514-cr01-tor1.ip.torix.ca, 8.0.108.206.in-addr.arpa domain
name pointer po1-56.400-cr01-tor2.ip.torix.ca, 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.

- three members doesn't meet community expectations

We made the policy and it reached consensus so it is assumed it certainly
does.

- The only people supporting are current IXP operators and they're confused

Not at all. Who better to comment on a policy that would affect a segment
of the infrastructure than the people who build it?

- Renumbering isn't that bad

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.

- Awards for the meeting

Kevin had the best commentary. Owen had the best stage presence.

Have a great weekend all,

-M<

On Wed, Nov 22, 2023 at 2:31 PM owen--- via ARIN-PPML <arin-ppml at arin.net>
wrote:

> Draft Policies:
>
> * ARIN-2023-2: /26 initial IPv4 allocation for IXPs
>
>
> 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.
>
> * 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)
>
>
> I look forward to the revision of this proposal based on the comments from
> the PPM.
>
> Owen
>
>
> _______________________________________________
> 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/20231208/abf85dc1/attachment.htm>