Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

["Md. Abdul Awal" <awal.ece@gmail.com>]

I support the proposal.

An organization may neither be currently mutihomed, nor intend to be multihomed in future, rather it just want to peer with a single provider should be eligible to get an ASN. I understand that the current policy doesn't force anyone to be actually multihomed in future, but at least collects their consent to do so, which sometimes may be just a fake consent.

Furthermore, an organization may not hold previously-allocated provider independent address space, rather holds addresses assigned by their ISP should also be eligible to get an ASN.

BR//Awal

On 22/1/19 6:14 AM, Bertrand Cherrier 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.palet@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

Attachment: signature.asc
Description: OpenPGP digital signature