<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">All of those would be covered by the “unique routing policy” language that I proposed.<div class=""><br class=""></div><div class="">On the other hand, prop-114 as written in the APNIC region proposes “I want an ASN”… “OK, here you go.”</div><div class=""><br class=""></div><div class="">I think that allowing anyone who wants one to get an ASN without any real need is not a good idea.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 7, 2015, at 23:10 , Noah Maina <<a href="mailto:mainanoa@gmail.com" class="">mainanoa@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">I would support such a proposal.</p><p dir="ltr" class="">1. There are situations where an organisation requires an ASN so that they can at most singlehome to one provider due to budget constraints in terms of the no. of upstream carriers they can connect too. This is very very common today. </p><p dir="ltr" class="">2. Some upstream providers have diverse paths or redundancies and as such an organisation could opt to go for such a provider knowing that there transit service would be guaranteed as long as they have a stable interconnect to such an upstream provider.</p><p dir="ltr" class="">3. An organisation would chose to multihome to a single upstream but to different sites of the same upstream...how about that..!!!</p><p dir="ltr" class="">4. One could justify the 2 upstream providers requirement to Afrinic for instance...but a few months down the finance year, they decided to terminate a contract with one upstream and stick with the other....Afrinic won't come calling as its not their business anywhere....thus it makes no sense emphasising 2 upstream providers as a criteria for getting an ASN because of the dynamics of business today.....</p><p dir="ltr" class="">My 2 cents....</p><p dir="ltr" class="">Noah</p>
<div class="gmail_quote">On 8 Feb 2015 06:39, "Ernest" <<a href="mailto:ernest@afrinic.net" class="">ernest@afrinic.net</a>> wrote:<br type="attribution" class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FYI - this could be of interest in our region.<br class="">
<br class="">
The proposal removes the need to multi-home as the only criteria to<br class="">
receive an ASN, replaces it with:<br class="">
<br class="">
" An organization is eligible for an ASN assignment if is planning<br class="">
to use it within next 6 months "<br class="">
<br class="">
More below.<br class="">
<br class="">
> -----------------------------------------------------------<br class="">
> prop-114-v001: Modification in the ASN eligibility criteria<br class="">
> -----------------------------------------------------------<br class="">
><br class="">
> Proposer: Aftab Siddiqui<br class="">
> <a href="mailto:aftab.siddiqui@gmail.com" class="">aftab.siddiqui@gmail.com</a><br class="">
><br class="">
> Skeeve Stevens<br class="">
> <a href="mailto:skeeve@eintellegonetworks.com" class="">skeeve@eintellegonetworks.com</a><br class="">
><br class="">
><br class="">
> 1. Problem statement<br class="">
> --------------------<br class="">
><br class="">
> The current ASN assignment policy dictates two eligibility criteria<br class="">
> and both should be fulfilled in order to get an ASN. The policy<br class="">
> seems to imply that both requirements i.e. multi-homing and clearly<br class="">
> defined single routing policy must be met simultaneously, this has<br class="">
> created much confusion in interpreting the policy.<br class="">
><br class="">
> As a result organizations have either provided incorrect information<br class="">
> to get the ASN or barred themselves from applying.<br class="">
><br class="">
><br class="">
> 2. Objective of policy change<br class="">
> -----------------------------<br class="">
><br class="">
> In order to make the policy guidelines simpler we are proposing to<br class="">
> modify the text describing the eligibility criteria for ASN<br class="">
> assignment by removing multi-homing requirement for the organization.<br class="">
><br class="">
><br class="">
> 3. Situation in other regions<br class="">
> -----------------------------<br class="">
><br class="">
> ARIN:<br class="">
> It is not mandatory but optional to be multi-homed in order get ASN<br class="">
><br class="">
> RIPE:<br class="">
> Policy to remove multi-homing requirement is currently in discussion<br class="">
> and the current phase ends 12 February 2015<br class="">
> Policy - <a href="https://www.ripe.net/ripe/policies/proposals/2014-03" target="_blank" class="">https://www.ripe.net/ripe/policies/proposals/2014-03</a><br class="">
><br class="">
> LACNIC:<br class="">
> only inter-connect is mandatory not multi-homing<br class="">
><br class="">
> AFRINIC:<br class="">
> It is mandatory to be multi-homed in order to get ASN.<br class="">
><br class="">
><br class="">
> 4. Proposed policy solution<br class="">
> ---------------------------<br class="">
><br class="">
> An organization is eligible for an ASN assignment if it:<br class="">
> - Is planning to use it within next 6 months<br class="">
><br class="">
><br class="">
> 5. Advantages / Disadvantages<br class="">
> -----------------------------<br class="">
><br class="">
> Advantages:<br class="">
><br class="">
> Removing the mandatory multi-homing requirement from the policy will<br class="">
> make sure that organizations are not tempted to provide wrong<br class="">
> information in order to fulfil the criteria of eligibility.<br class="">
><br class="">
> Disadvantages:<br class="">
><br class="">
> No disadvantage.<br class="">
><br class="">
><br class="">
> 6. Impact on resource holders<br class="">
> -----------------------------<br class="">
><br class="">
> No impact on existing resource holders.<br class="">
><br class="">
><br class="">
> 7. References<br class="">
> -------------<br class="">
><br class="">
> * sig-policy: APNIC SIG on resource management policy *<br class="">
> _______________________________________________<br class="">
> sig-policy mailing list<br class="">
> <a href="mailto:sig-policy@lists.apnic.net" class="">sig-policy@lists.apnic.net</a><br class="">
> <a href="http://mailman.apnic.net/mailman/listinfo/sig-policy" target="_blank" class="">http://mailman.apnic.net/mailman/listinfo/sig-policy</a><br class="">
_______________________________________________<br class="">
rpd mailing list<br class="">
<a href="mailto:rpd@afrinic.net" class="">rpd@afrinic.net</a><br class="">
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank" class="">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br class="">
</blockquote></div>
_______________________________________________<br class="">rpd mailing list<br class=""><a href="mailto:rpd@afrinic.net" class="">rpd@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo.cgi/rpd<br class=""></div></blockquote></div><br class=""></div></body></html>