If someone uses a private ASN to announce a route, that route still takes RIB/FIB space, it just has its origin ASN as the upstream provider's ASN.
-Scott On Sat, Sep 17, 2022 at 10:22 PM Adam Thompson <[email protected]> wrote: > I’m on the fence. > > > > I think the scarce resource is no longer 16-bit ASNs but is now FIB space > on routers. I even know of a few where RIB space is the issue, not FIB. > We’re not – that I know of – about to hit another 512k day or similar in > the next six months, but there are a lot of routers out there that can only > handle 1M IPv4-sized routes. > > > > I agree with your logic (the comparison to RFC1918) but I am concerned > about an explosion of ASNs and corresponding routes. I’m assuming an > explosion of ASNs will equate an explosion of routes, v4 and/or v6, as > otherwise, why would you need a public ASN? > > > > Separately, I don’t see anything wrong with the modifications proposed in > the Staff Review – they seem sound, although I wish the full proposed > rewritten section had been included, in addition to the item-wise > commentary. > > > > -Adam > > > > *Adam Thompson* > > Consultant, Infrastructure Services > > [image: MERLIN] > > 100 - 135 Innovation Drive > > Winnipeg, MB R3T 6A8 > > (204) 977-6824 or 1-800-430-6404 (MB only) > > https://www.merlin.mb.ca > > Chat with me on Teams > <https://teams.microsoft.com/l/chat/0/[email protected]> > > > > *From:* ARIN-PPML <[email protected]> *On Behalf Of *Scott > Leibrand > *Sent:* September 13, 2022 12:20 PM > *To:* ARIN <[email protected]> > *Cc:* PPML <[email protected]> > *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2022-2: Remove > Barrier to BGP Uptake in ASN Policy > > > > I support this. > > Scott > > > > On Sep 13, 2022, at 7:46 AM, ARIN <[email protected]> wrote: > > > > The following Draft Policy has been revised: > > > > * ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy > > > > Revised text is below and can be found at: > > > > https://www.arin.net/participate/policy/drafts/2022_2/ > > > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion to assess the conformance of this Draft Policy with > ARIN's Principles of Internet number resource policy as stated in the > Policy Development Process (PDP). Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The PDP can be found at: > > https://www.arin.net/participate/policy/pdp/ > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/participate/policy/drafts/ > > > > Regards, > > > > Sean Hopkins > > Senior Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy > > > > Problem Statement: > > > > The current requirements for getting an ASN have resulted in confusion > particularly for new entrants, who have their hands more than full with the > mechanics of getting BGP up and running. The availability of 32 bit ASNs > provides an opportunity for the removal of unnecessary constraints and > processes for the allocation of ASNs. > > > > ARIN does not provide guidance to use RFC1918 space if possible and > likewise ARIN should not require the use of private ASNs in preference to > public ASNs. > > > > Further Technical Rationale: > > > > Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has > taken several years for routing equipment in general use to catch up, but > today 32 bit ASNs are generally accepted and it is rare that an > organization which has been issued a 32 bit ASN comes back to ARIN and says > they need a 16 bit ASN instead. > > > > The austerity measure of requiring extensive documentation to get an ASN > is left over from the days of 16 bit ASNs (total space 65000). It is no > longer appropriate and we should align our conservation requirements with > those found in other 32-bit spaces (total space four billion). Consider: > > > > A /32 of IPv6 space is the default allocation and will be assigned to any > ISP that requests it. > > > > Temporary assignment of a /32 of IPv4 space can be acquired on most > residential ISPs by issuing a DHCP request. > > > > We propose making issuance of the first 32 bit ASN for any ORGID (or each > site for organizations that have number resources under multiple discrete > networks policy) be pro-forma upon request. If an org’s technical people > think they need a public ASN, they probably do! > > > > Policy statement: > > > > Replace the entirety of Section 5, which currently reads: > > > > There are a limited number of available Autonomous System Numbers (AS > Numbers), therefore, it is important to determine which sites require > unique ASNs and which do not. If a unique ASN is not required for a given > network design, one or more of the ASN reserved for private use should be > utilized. Those numbers are: 64512 through 65534 > and 4200000000 through 4294967294 inclusive. > > > > In order to be assigned an ASN, each requesting organization must provide > ARIN with verification that it requires a unique routing policy, such as a > plan: > > > > To originate announcement of IP Number Resources via an accepted protocol > (such as Border Gateway Protocol) from an ASN different than that of its > upstream provider; > > > > To multihome a site with one or more Autonomous Systems; or > > > > To use an ASN to interconnect with other Autonomous Systems. > > > > ASNs are issued based on current need, as set out in this section 5. > > > > With the following new Section 5: > > > > Any organization may be issued a single Autonomous System Number (ASN) > upon request. Organizations that have space issued under Multiple Discrete > Networks policy may be issued one ASN per discrete network upon request. > > > > Additional ASN requests should include proof of the requestor's need for a > unique routing policy, or other technical justification for the need for > more than one ASN. > > > > Timetable for implementation: Immediate > > _______________________________________________ > 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.
