So a "maybe someday" ASN?

So anyone who has PI space and doesn't already have an ASN gets allocated
one regardless of need.
Any new member who gets PI space gets an ASN allocated as a matter of
course.

Any additional ASN requested by a member must conform to existing policy.

Is this where we're at?  Change the proposal and see where we get to.

Why not make it your APNIC membership number and be done with it :). That
lowers the barrier even further and means that people wouldn't need
assistance applying for them.



On Saturday, 28 February 2015, Owen DeLong <o...@delong.com> wrote:

>
> > On Feb 27, 2015, at 01:43 , Izumi Okutani <iz...@nic.ad.jp
> <javascript:;>> wrote:
> >
> > On 2015/02/27 17:58, Usman Latif wrote:
> >> I think organisations that have obtained portable address ranges from
> RIRs should have the liberty to use public ASNs from day one (if they want
> to) regardless of whether they are single homed or multihomed.
> >>
> >
> > OK, that's an interesting approach.
> >
> > What is the reason for this? Would be curious to hear from other
> > operators as well, on what issues it may cause if you are a single homed
> > portable assignment holder and cannot receive a global ASN.
>
> I can see a few reasons.
>
> 1.      The difficulty of renumbering from a private ASN is proportional
> to the number of links,
>         not the number of ASNs. Ergo, someone who is single homed, but
> plans to become
>         multihomed at some unspecified date in the future may, indeed,
> have good reason for
>         wanting to do so with a public ASN.
>
> 2.      I see very little harm in adopting such a policy, so long as it is
> limited to one ASN per
>         organization.
>
> 3.      If you have multiple links to a provider with diverse topology, it
> is desirable to be able
>         to use a routing protocol in order to prevent black-holing traffic
> across down links, etc.
>         The only routing protocol any sane ISP would run with an unrelated
> third party is
>         BGP. BGP requires an ASN. See above for why a public ASN may be
> more desirable
>         under this circumstance than a private one.
>
> As to the references to RFC-1930, I think they are anachronistic at this
> point.
>
> RFC-1930 was written before 32-bit ASNs were available and with a strong
> eye to the
> coming shortage of 16-bit ASNs. While I agree that even the 32-bit pool of
> ASNs is finite,
> I don’t think we’re going to cause a shortage of them by allowing
> single-homed organizations
> with PI space who plan to multihome at an unspecified future time to
> receive one.
>
> As such, I believe such a policy would do no harm and provide benefit to
> some members
> of the community. If it were proposed, I would support it.
>
> Owen
>
> *              sig-policy:  APNIC SIG on resource management policy
>    *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net <javascript:;>
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>


-- 
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.
*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to