Hi Jordi,
We updated this requirement after a year-long discussion within the
community. It doesn't enforce you to multi-home but suggests you should in
the future. I don't see this as a roadblock in receiving PI address space.

Regards,

Aftab A. Siddiqui


On Tue, Jan 22, 2019 at 11:14 AM Bertrand Cherrier <b.cherr...@micrologic.nc>
wrote:

> Dear SIG members,
>
> The proposal "prop-128-v001: Multihoming not required for ASN" has been
> sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 47 in
> Daejeon, South Korea on Wednesday, 27 February 2019.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
>
>    - Do you support or oppose this proposal?
>    - Does this proposal solve a problem you are experiencing? If so, tell
>    the community about your situation.
>    - Do you see any disadvantages in this proposal?
>    - Is there anything in the proposal that is not clear?
>    - What changes could be made to this proposal to make it more
>    effective?
>
> Information about this proposal is available at:
>
>  http://www.apnic.net/policy/proposals/prop-128
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> ------------------------------
>
> prop-128-v001: Multihoming not required for ASN
> ------------------------------
>
> Proposers: Jordi Palet Martínez
> jordi.pa...@theipv6company.com
> 1. Problem Statement
>
> When the ASN assignment policy was originally designed, the reliability
> of networks was not so good as today. So, at that time, it was making
> sense to make sure that and ASN holder is multihomed.
>
> However, today this is not necessarily a reasonable requirement, and
> even in some cases, some networks may require an ASN and not willing
> to be multihomed (because the cost, or remote locations that have only
> a single upstream, etc.), and their SLA requirements don’t need that
> redundancy.
>
> The deployment of IPv6 also increase the need for organizations which
> are not ISPs, to obtain IPv6 PI in order to have stable addresses,
> and in that situation, ideally, they should announce their PI space
> with their own ASN. In most cases, they don’t have to be multihomed.
> 2. Objective of policy change
>
> To ensure that organizations which have their own routing policy and
> the need to interconnect with other organizations, can do it.
>
> Interconnect is used here with the commonly understood meaning of
> establishing a connection between two (administratively) separate
> networks.
> 3. Situation in other regions
>
> ARIN and LACNIC don’t require multihoming. RIPE requires it. AfriNIC has
> a policy equivalent to APNIC, but I’m submitting a proposal similar to
> this one to change it as well as in the case of RIPE.
> 4. Proposed policy solution
>
> Current Policy text
>
> 12.1. Evaluation of eligibility
>
> An organization is eligible for an ASN assignment if:
> - it is currently multihomed, or
> - it holds previously-allocated provider independent address space and
> intends to multihome in the future.
>
> An organization will also be eligible if it can demonstrate that it will
> meet the above criteria upon receiving an ASN (or within a reasonably
> short time thereafter).
>
> Requests for ASNs under these criteria will be evaluated using the
> guidelines described in RFC1930 'Guidelines for the creation, selection
> and registration of an Autonomous System' (AS).
>
> Proposed text
>
> 12.1. Evaluation of eligibility
>
> An organization is eligible for an ASN assignment if:
> - it is multihomed or
> - has the need to interconnect with other AS.
>
> An organization will also be eligible if it can demonstrate that it will
> meet any
> of the above criteria upon receiving an ASN (or within a reasonably
> short time thereafter).
>
> Requests for ASNs under these criteria will be evaluated using the
> guidelines described in RFC1930 'Guidelines for the creation, selection
> and registration of
> an Autonomous System' (AS).
> 5. Advantages / Disadvantages
>
> Advantages:
> Fulfilling the objectives above indicated.
>
> Disadvantages:
> None foreseen.
> 6. Impact on resource holders
>
> None.
> 7. References
>
> https://www.arin.net/policy/nrpm.html#five
> https://www.lacnic.net/683/2/lacnic/
> https://www.ripe.net/publications/docs/ripe-679
> *              sig-policy:  APNIC SIG on resource management policy
>    *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to