Hi again Satoru, and once more many thanks for the inputs,
If we keep “it holds previously-allocated provider independent address space”, then it means an organization, for example, deploying only IPv6, will not be able to get an ASN. Or even an organization willing to get IPv4, can’t get it from APNIC. Should them then wait for available IPv4 space and not have their own ASN meanwhile? Or should they “promise” “I will multihome” and actually never do it? (there is no a concrete time term defined in the policy). Or going to the extreme. Should the organization get IPv4 PI, but actually not use it? Or should the organization request IPv6 PI today and tomorrow an ASN ? It is artificial! If we really want to ensure that those organizations multihome, we really need to fix in how much time, and that was already changed in proposal 114. I think this proposal improves that, going to the point where probably prop-114 wanted to be (but sometimes you need to go step by step …). In general, I don’t think restricting non-scarce resources as ASN is a good thing, and if that happens APNIC should report it back to the community and then we may consider it back. Current text is artificial in the sense that already prop-114 expressed. People can just lie “I will …”. Regards, Jordi De: <[email protected]> en nombre de Satoru Tsurumaki <[email protected]> Fecha: viernes, 22 de febrero de 2019, 12:30 Para: Policy SIG <[email protected]> Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-128, based on a meeting we organized on 12th Feb to discuss these proposals. Substantial support expressed, subject to not deleting the "it holds previously-allocated provider independent address space" described in the current policy text. * In this proposal, "it holds previously-allocated provider independent address space" is erased. it should keep it in order to prevent unnecessary application of AS number. * In the case of IPv6, the NAT disappears and the global address is assigned to all device in the organization. If each organization uses a PI address that is not locked in to a upper provider, there is a great merit that there is no need to procure the second transit. *There are areas where have only one transit as pointed out by the proposer. This proposal has the effect that policy conforms to the actual situation as a result. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月22日(火) 9:14 Bertrand Cherrier <[email protected]>: 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 [email protected] 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 [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
