Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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
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.cherrier@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.palet@theipv6company.com
- 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
HI Aftab,
Thanks for providing inputs!
My reading of the actual policy is that it actually enforces the multihoming “in a reasonable 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).
So, the question I’m trying to solve is what if I can’t or don’t want to multihome? I’m an SME, I want to have my own IPv6 PI announced with my own ASN, however I’m fine not multihoming.
Regards,
Jordi
De: sig-policy-bounces@lists.apnic.net en nombre de Aftab Siddiqui aftab.siddiqui@gmail.com Fecha: jueves, 24 de enero de 2019, 2:28 Para: Policy SIG sig-policy@apnic.net Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN
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.cherrier@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.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
* 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
********************************************** 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.
Hi Jordi,
My reading of the actual policy is that it actually enforces the multihoming “in a reasonable 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).
I still believe it is not enforcement. Because this statement came out of the policy change which I co-authored :)
So, the question I’m trying to solve is what if I can’t or don’t want to multihome? I’m an SME, I want to have my own IPv6 PI announced with my own ASN, however I’m fine not multihoming.
I totally agree with your point of view and if you read the first version [1] of my proposal back in 2015, it was not asking for multihoming requirement at all but community suggested that there are not enough evidence to prove that someone will get an ASN and Address space and won't multihome in the future. You have to show intention as part of the application requirement. Previously, you were suppose to provide ASN details where you WILL multihome which was remove after prop-114.
[1] - https://www.apnic.net/wp-content/uploads/prop-114/assets/prop-114-v001.txt
Regards,
Jordi
*De: *sig-policy-bounces@lists.apnic.net en nombre de Aftab Siddiqui < aftab.siddiqui@gmail.com> *Fecha: *jueves, 24 de enero de 2019, 2:28 *Para: *Policy SIG sig-policy@apnic.net *Asunto: *Re: [sig-policy] prop-128-v001: Multihoming not required for ASN
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.cherrier@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.palet@theipv6company.com
- 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
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.
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 mailto:jordi.palet@theipv6company.com
1. Problem StatementWhen 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 changeTo 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 regionsARIN 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 solutionCurrent 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 / DisadvantagesAdvantages: Fulfilling the objectives above indicated.
Disadvantages: None foreseen.
6. Impact on resource holdersNone.
7. Referenceshttps://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
Activity Summary
- 1556 days inactive
- 1556 days old
- sig-policy@lists.apnic.net
- 4 participants
- 4 comments