<div dir="ltr">6.10.1 and 4.4 speak to critical infrastructure. 6.10.1 has the more concise definition and is quoted below. 4.4 has been edited, but includes the same components, just more spread out.<div><br></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"> ARIN will make micro-allocations to critical infrastructure providers of the Internet, </span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"> including public exchange points, </span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">core DNS service providers (e.g. ICANN-sanctioned</span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"> root, gTLD, and ccTLD operators) as well as the RIRs and IANA.</span> </div><div><br></div><div>So, I think understand the issue as they relate to internet exchanges, they have been and are being discussed. However, I'm not certain these issues are as pressing for core DNS service providers, or at least any more than any other internet edge ASN. Could someone with experience with core DNS comment on that issue?</div><div><br></div><div>So, maybe we should reserve any returned 2-byte ASN for internet exchanges and not include core DNS. Unless someone has a convincing argument why this is an issue for core DNS. </div><div><br></div><div>Allow transfers, but any 2-byte ASNs returned to the free pool would be reserved for internet exchanges. Everyone else would get 4-byte ASNs out of the free pool. If there aren't any 2-byte ASNs available, or if they request request one, internet exchanges would receive a 4-byte ASN.</div><div><br></div><div>Just an idea that I thought I would put out there.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 3, 2016 at 7:15 PM, Adam Thompson <span dir="ltr"><<a href="mailto:athompso@athompso.net" target="_blank">athompso@athompso.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
(IMHO, and I know this is highly debatable but this isn't the place,
BGP communities are a mis-feature anyway.)<br>
<br>
Regardless, reserving 2-byte ASNs for "critical infrastructure" is a
good compromise if the restrictions mirror those for the IPv4 block
also reserved for "critical infrastructure".<br>
<br>
-Adam<br>
<br>
<br>
<div>On 2016-04-03 13:52, Ron Grant wrote:<br>
</div>
<blockquote type="cite">
The biggest technical problem with 4-byte ASNs that I'm aware of
comes when propagating BGP communities - AFAIK even with extended
communities, you can't specify two 4-byte ASNs in a single
community.<br>
<br>
This can be worked around when using communities for direct
peering arrangements, as one side of the equation is static - but
at a Public Exchange point, it can be problematic, because who
knows who might want to connect or not connect to whom.<br>
<br>
Recently we ran into this problem when requesting an ASN for the
Vancouver Internet Exchange (VANIX) - we were told there were no
2-byte ASNs left, so we went back to the drawing board to see how
we could run our Route Server with a 4-byte ASN, and after
wrestling with the problem for a few weeks, went back to ARIN
and...joy!...someone had returned a 2-byte, which we obtained for
the RS.<br>
<br>
IMO any future returned 2-byte ASNs should be reserved for
critical infrastructure or special need, but I'd love to find a
solution to the communities issue that made 2-byte ASNs "not
special" anymore.<br>
<br>
<br>
<br>
<br>
<div>On 2016-04-03 11:36 AM, Adam Thompson
wrote:<br>
</div>
<blockquote type="cite">IMO, 2-byte ASNs should simply be retired and not
reallocated. "Solving the technical problem", as described in
your email, is actually ensuring the perpetuation of a different
technical problem.<br>
It's the same sort of thing as the IPv4 vs IPv6 --transition,
but this time ARIN has an opportunity to at least avoid being
part of the problem, even if it can't really be part of the
"solution".<br>
Let's please not prolong this problem, too... even in central
Canada, known for a paucity of upstream carriers, it's now
commercially feasible to work around the 2-byte technical
limitations.<br>
<br>
-Adam<br>
<br>
<br>
<div class="gmail_quote">On April 3, 2016 12:59:37 PM CDT,
Andrew Dul <a href="mailto:andrew.dul@quark.net" target="_blank"><andrew.dul@quark.net></a>
wrote:
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<pre>Hello,
I am starting a new thread in PPML, as a follow up to the ARIN
suggestion and consultation which recently started regarding creating a
2-byte ASN waiting list.
The original suggestion is here:
<a href="https://www.arin.net/participate/acsp/suggestions/2016-04.html" target="_blank">https://www.arin.net/participate/acsp/suggestions/2016-04.html</a>
ARIN opened a consultation on this suggestion on the arin-consult
mailing-list. This thread starts here for those who are not subscribed
to arin-consult.
<a href="http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html" target="_blank">http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html</a>
<a href="http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html" target="_blank">http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html</a>
As the thread evolved it has been suggested that this issue should be
resolved via the policy development process rather than through a
suggestion.
There are a number of questions that have been raised by this thread. I
am copying them here to continue the discussion on PPML.
===
Working problem statement: ARIN will receive 2-byte ASNs as returns
over time, and these ASNs have perceived or additional value to
organizations compared to 4-byte ASNs. How should ARIN allocate these
2-byte ASNs?
===
Should they be given to the next requester, regardless of technical need
for a 2-byte ASN? (What are the technical qualifications we should use
if there is a specific technical need? e.g. provides transit to more
than 1 ASN?)
If there is really a technical need for 2-byte ASNs, shouldn't we
attempt to build an inventory of 2-byte ASNs?
Should returns be held in reserve?
Should ARIN hold them for some period of
time
before reallocating them?
Should they be put up for auction to qualified organizations?
Should they be given to the 1st organization on a wait-list for 2-byte
ASNs?
Would an organization looking for a 2-byte ASN have the option to
receive a 4-byte ASN in the interim? If they did would they have to
return it?
Should the waiting list be closed to organizations that already have a
2-byte ASNs?
I and the AC would appreciate your comments on these questions so that
we can start to build a draft policy that best matches with what the
community would like to see implemented by ARIN.
Thanks,
Andrew
<hr>
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
</pre></blockquote></div>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
<fieldset></fieldset>
<pre>_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<pre cols="72">--
Ron Grant Managed DSL/Cable/Wireless/Fibre
Skyway West Business Internet Internet and Private Networking
<a href="mailto:rgrant@skywaywest.com" target="_blank">rgrant@skywaywest.com</a> Bonding and Fail Over Solutions
cell: <a href="tel:604-737-2113" value="+16047372113" target="_blank">604-737-2113</a> Virtual Data Centre and Private Clouds
direct: <a href="tel:604-484-5263" value="+16044845263" target="_blank">604-484-5263</a> <a href="http://www.skywaywest.com" target="_blank">http://www.skywaywest.com</a>
Sales, Support and Billing <a href="http://www.skywaywest.com/contact-us.htm" target="_blank">http://www.skywaywest.com/contact-us.htm</a>
<a href="http://ca.linkedin.com/in/obiron" target="_blank">ca.linkedin.com/in/obiron</a>
</pre>
</font></span></blockquote>
</div><br>_______________________________________________<br>
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">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div>
</div>