Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
[sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Dear SIG members
The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015.
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-114
Regards,
Masato
----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria -----------------------------------------------------------
Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com
Skeeve Stevens skeeve@eintellegonetworks.com
1. Problem statement --------------------
The current ASN assignment policy dictates two eligibility criteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying.
2. Objective of policy change -----------------------------
In order to make the policy guidelines simpler we are proposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions -----------------------------
ARIN: It is not mandatory but optional to be multi-homed in order get ASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing
AFRINIC: It is mandatory to be multi-homed in order to get ASN.
4. Proposed policy solution ---------------------------
An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months
5. Advantages / Disadvantages -----------------------------
Advantages:
Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility.
Disadvantages:
No disadvantage.
6. Impact on resource holders -----------------------------
No impact on existing resource holders.
7. References -------------
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi myamanis@gmail.com wrote:
Dear SIG members
The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015.
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-114Regards,
Masato
prop-114-v001: Modification in the ASN eligibility criteria
Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');
Skeeve Stevens skeeve@eintellegonetworks.comjavascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');
- Problem statement
The current ASN assignment policy dictates two eligibility criteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy. As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying.
- Objective of policy change
In order to make the policy guidelines simpler we are proposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
- Situation in other regions
ARIN: It is not mandatory but optional to be multi-homed in order get ASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing
AFRINIC: It is mandatory to be multi-homed in order to get ASN.
- Proposed policy solution
An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months
- Advantages / Disadvantages
Advantages:
Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility.Disadvantages:
No disadvantage.
- Impact on resource holders
No impact on existing resource holders.
- References
Hi Dean, Thanks for raising the question.
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
Would like to add something here to the question, "have you even been made aware of a situation where applicant provided wrong or fake multi-homing information just to meet the criteria?"
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
Very valid point.
Regards,
Aftab A. Siddiqui
Changing or removing the rules is not the way to address people submitting invalid or misleading information.
Also I doubt that the hostmasters would be 'aware' of a case. If they were then the question would be why did they approve the resource application.
On Wednesday, 4 February 2015, Aftab Siddiqui aftab.siddiqui@gmail.com wrote:
Hi Dean, Thanks for raising the question.
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
Would like to add something here to the question, "have you even been made aware of a situation where applicant provided wrong or fake multi-homing information just to meet the criteria?"
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
Very valid point.
Regards,
Aftab A. Siddiqui
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015. 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibility criteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy. As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we are proposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization. 3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in order get ASN RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo george@apnic.net wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 inFukuoka, Japan on Thursday, 5 March 2015.
We invite you to review and comment on the proposal on the mailinglist 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? Ifso, 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibilitycriteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we are proposingto modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in order getASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton dean@internetnz.net.nz wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo george@apnic.net wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote: Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015. 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibility criteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy. As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we are proposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization. 3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in order get ASN RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
You're right that it's just one data point. I'd encourage anyone with any further information to present it.
At the moment I'm not seeing the requirement here.
On Friday, 6 February 2015, Owen DeLong owen@delong.com wrote:
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton <dean@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.nz');> wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo <george@apnic.net javascript:_e(%7B%7D,'cvml','george@apnic.net');> wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 inFukuoka, Japan on Thursday, 5 March 2015.
We invite you to review and comment on the proposal on the mailinglist 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? Ifso, 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibilitycriteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we are proposingto modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in order getASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.nz');
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net'); http://mailman.apnic.net/mailman/listinfo/sig-policy
hahahahahahahahahah
"...to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present."
This made my morning.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong owen@delong.com wrote:
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton dean@internetnz.net.nz wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo george@apnic.net wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 inFukuoka, Japan on Thursday, 5 March 2015.
We invite you to review and comment on the proposal on the mailinglist 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? Ifso, 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibilitycriteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we are proposingto modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in order getASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Rather than being a laughing matter this proposal seeks to hand out ASNs with no more justification than "I want one".
Can the authors explain why they feel radical change to existing policy is required?
On Friday, 6 February 2015, Skeeve Stevens skeeve@v4now.com wrote:
hahahahahahahahahah
"...to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present."
This made my morning.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com javascript:_e(%7B%7D,'cvml','skeeve@v4now.com'); ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong <owen@delong.com javascript:_e(%7B%7D,'cvml','owen@delong.com');> wrote:
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton <dean@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.nz');> wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo <george@apnic.net javascript:_e(%7B%7D,'cvml','george@apnic.net');> wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibilitycriteria" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 39 inFukuoka, Japan on Thursday, 5 March 2015.
We invite you to review and comment on the proposal on the mailinglist 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 youto express your views on the proposal:
- Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? Ifso, 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibilitycriteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we areproposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in orderget ASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.nz');
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net'); http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net'); http://mailman.apnic.net/mailman/listinfo/sig-policy
I do agree with Dean that this proposal in its current state is too radical, but I do support relaxing the requirements to multi home _or_ unique routing policy would be an improvement that addresses the issue raised in the problem statement.
Owen
On Feb 5, 2015, at 12:07, Skeeve Stevens skeeve@v4now.com wrote:
hahahahahahahahahah
"...to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present."
This made my morning.
...Skeeve
Skeeve Stevens - Senior IP Broker v4Now - an eintellego Networks service skeeve@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong owen@delong.com wrote: I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton dean@internetnz.net.nz wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo george@apnic.net wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote: Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015. 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibility criteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy. As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we are proposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization. 3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in order get ASN RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
There is a version of this that I would support, this isn't it.
On Sunday, 8 February 2015, Owen DeLong owen@delong.com wrote:
I do agree with Dean that this proposal in its current state is too radical, but I do support relaxing the requirements to multi home _or_ unique routing policy would be an improvement that addresses the issue raised in the problem statement.
Owen
On Feb 5, 2015, at 12:07, Skeeve Stevens <skeeve@v4now.com javascript:_e(%7B%7D,'cvml','skeeve@v4now.com');> wrote:
hahahahahahahahahah
"...to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present."
This made my morning.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com javascript:_e(%7B%7D,'cvml','skeeve@v4now.com'); ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong <owen@delong.com javascript:_e(%7B%7D,'cvml','owen@delong.com');> wrote:
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton <dean@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.nz');> wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo <george@apnic.net javascript:_e(%7B%7D,'cvml','george@apnic.net');> wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibilitycriteria" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 39 inFukuoka, Japan on Thursday, 5 March 2015.
We invite you to review and comment on the proposal on the mailinglist 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 youto express your views on the proposal:
- Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? Ifso, 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibilitycriteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we areproposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in orderget ASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility. Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.nz');
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net'); http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net'); http://mailman.apnic.net/mailman/listinfo/sig-policy
Dean,
Pleas enlighten us on what version you would support.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Sun, Feb 8, 2015 at 11:49 AM, Dean Pemberton dean@internetnz.net.nz wrote:
There is a version of this that I would support, this isn't it.
On Sunday, 8 February 2015, Owen DeLong owen@delong.com wrote:
I do agree with Dean that this proposal in its current state is too radical, but I do support relaxing the requirements to multi home _or_ unique routing policy would be an improvement that addresses the issue raised in the problem statement.
Owen
On Feb 5, 2015, at 12:07, Skeeve Stevens skeeve@v4now.com wrote:
hahahahahahahahahah
"...to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present."
This made my morning.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong owen@delong.com wrote:
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton dean@internetnz.net.nz wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo george@apnic.net wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibilitycriteria" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 39 inFukuoka, Japan on Thursday, 5 March 2015.
We invite you to review and comment on the proposal on the mailinglist before the meeting.
The comment period on the mailing list before an APNIC meeting isan 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibilitycriteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we areproposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in orderget ASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from thepolicy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility.
Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Dear Colleagues,
Regarding prop-114, discussion points are;
1. Whether completely taking away multi-home requirement or relaxing it by adding "or unique routing policy" as Owen proposed and ARIN doing.
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00015.h...
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00044.h...
2. Whether we will relax it for only 4-byte AS or 2-byte also. (Please note that we are running out 2-byte AS and it might speed it up)
It is very appreciated if you will express your views for these points, and also show another points if you have.
Regards, Masato
2015-02-07 19:25 GMT-06:00 Skeeve Stevens skeeve@v4now.com:
Dean,
Pleas enlighten us on what version you would support.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Sun, Feb 8, 2015 at 11:49 AM, Dean Pemberton dean@internetnz.net.nz wrote:
There is a version of this that I would support, this isn't it.
On Sunday, 8 February 2015, Owen DeLong owen@delong.com wrote:
I do agree with Dean that this proposal in its current state is too radical, but I do support relaxing the requirements to multi home _or_ unique routing policy would be an improvement that addresses the issue raised in the problem statement.
Owen
On Feb 5, 2015, at 12:07, Skeeve Stevens skeeve@v4now.com wrote:
hahahahahahahahahah
"...to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present."
This made my morning.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong owen@delong.com wrote:
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton dean@internetnz.net.nz wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo george@apnic.net wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
Could I ask that the APNIC hostmasters to comment on the following:
Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to?
In other words has the current policy in the eyes of the host masters ever been a barrier to entry?
On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com mailto:myamanis@gmail.com> wrote:
Dear SIG members The proposal "prop-114: Modification in the ASN eligibilitycriteria" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 39 inFukuoka, Japan on Thursday, 5 March 2015.
We invite you to review and comment on the proposal on themailing list before the meeting.
The comment period on the mailing list before an APNIC meeting isan 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-114 Regards, Masato ----------------------------------------------------------- prop-114-v001: Modification in the ASN eligibility criteria ----------------------------------------------------------- Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com <javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com');> Skeeve Stevens skeeve@eintellegonetworks.com <javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com');> 1. Problem statement -------------------- The current ASN assignment policy dictates two eligibilitycriteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy.
As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying. 2. Objective of policy change ----------------------------- In order to make the policy guidelines simpler we areproposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
3. Situation in other regions ----------------------------- ARIN: It is not mandatory but optional to be multi-homed in orderget ASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing AFRINIC: It is mandatory to be multi-homed in order to get ASN. 4. Proposed policy solution --------------------------- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months 5. Advantages / Disadvantages ----------------------------- Advantages: Removing the mandatory multi-homing requirement from thepolicy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility.
Disadvantages: No disadvantage. 6. Impact on resource holders ----------------------------- No impact on existing resource holders. 7. References ---------------
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
Secondly, In considering this policy proposal in conjunction with prop-113, I am increasingly doubtful that there is anything for me to support here.
I suspect what is happening here is that these proposals (113 and 114) are conjoined and rather than significantly lowering the bar with regard to allocation of IPv4 resources, they seek removal of the bar altogether.
There are players within the community who will significantly benefit from a policy framework with a reduced multi-homing and demonstrated needs requirement, but those entities are not necessarily the end LIRs.
What these two proposals seek to do is remove all barriers to obtaining IPv4 addresses and ASNs. One of the major problems here is that the authors seek to do this one 'cut' at a time. Almost in an attempt to avoid waking the tiger which is ARIN's requirement for needs based allocation, or having the APNIC community discussion around 'needs based' allocation for IPv4 resources.
I would like to see us stop the subterfuge here.
I would like to see both of these policies withdrawn and prop-116 "Removal of all barriers to allocation of IPv4 and ASN resources" put forward for debate. It is only in that way that the true ramifications/impacts of these smaller policies can be realised and discussed by the community.
Forcing us to debate this clause by clause is a waste of community time and effort.
I strongly oppose this policy as it is currently written.
Dean
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Tue, Feb 24, 2015 at 7:38 AM, Masato Yamanishi myamanis@gmail.com wrote:
Dear Colleagues,
Regarding prop-114, discussion points are;
- Whether completely taking away multi-home requirement or relaxing it by
adding "or unique routing policy" as Owen proposed and ARIN doing.
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00015.h...
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00044.h...
- Whether we will relax it for only 4-byte AS or 2-byte also. (Please note that we are running out 2-byte AS and it might speed it
up)
It is very appreciated if you will express your views for these points, and also show another points if you have.
Regards, Masato
2015-02-07 19:25 GMT-06:00 Skeeve Stevens skeeve@v4now.com:
Dean,
Pleas enlighten us on what version you would support.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Sun, Feb 8, 2015 at 11:49 AM, Dean Pemberton dean@internetnz.net.nz wrote:
There is a version of this that I would support, this isn't it.
On Sunday, 8 February 2015, Owen DeLong owen@delong.com wrote:
I do agree with Dean that this proposal in its current state is too radical, but I do support relaxing the requirements to multi home _or_ unique routing policy would be an improvement that addresses the issue raised in the problem statement.
Owen
On Feb 5, 2015, at 12:07, Skeeve Stevens skeeve@v4now.com wrote:
hahahahahahahahahah
"...to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present."
This made my morning.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong owen@delong.com wrote:
I don't think your conclusion is supported by the statement from hostmaster...
"We don't know of anyone who hasn't reached out to us" doesn't mean that nobody has reached out to them... It means that they are unaware.
Asking the hostmasters about this issue in the way you did is akin to walking into a room full of people and saying "Everyone who is not here, please raise your hand" and concluding from the lack of raised hands that everyone is present.
Owen
On Feb 4, 2015, at 8:09 PM, Dean Pemberton dean@internetnz.net.nz wrote:
So it doesn't look like there is a problem here.
The hostmasters are clear about the current policy, they explain it to people who contact them.
Am I missing something? I'm not at all in favour of policy for policy sake.
What's the problem statement here?
On Thursday, 5 February 2015, George Kuo george@apnic.net wrote:
Hello Dean,
We are not aware of any potential members who may have decided not to apply for IPv4 addresses or AS numbers based on how they have interpreted the policy wording.
However, we explain the policy criteria to any potential members who do contact APNIC, and those who are not multihoming do not qualify for An IPv4 or ASN assignment based on the current policy.
Currently, we don't keep a record of these unsuccessful requests, but we can begin to keep records in the future if this information is required.
George K
On 4/02/2015 5:13 am, Dean Pemberton wrote:
> Could I ask that the APNIC hostmasters to comment on the following: > > Have you ever been made aware of a situation where due of the current > wording of the relevant clauses in the policy, a member or potential > member has not made a resource application where they would otherwise > have been able to? > > In other words has the current policy in the eyes of the host masters > ever been a barrier to entry? > > > > > On Wednesday, 4 February 2015, Masato Yamanishi <myamanis@gmail.com > mailto:myamanis@gmail.com> wrote: > > Dear SIG members > > The proposal "prop-114: Modification in the ASN eligibility > criteria" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 39 in > Fukuoka, > Japan on Thursday, 5 March 2015. > > 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-114 > > > Regards, > > Masato > > > > > > ----------------------------------------------------------- > prop-114-v001: Modification in the ASN eligibility criteria > ----------------------------------------------------------- > > Proposer: Aftab Siddiqui > aftab.siddiqui@gmail.com > javascript:_e(%7B%7D,'cvml','aftab.siddiqui@gmail.com'); > > Skeeve Stevens > skeeve@eintellegonetworks.com > javascript:_e(%7B%7D,'cvml','skeeve@eintellegonetworks.com'); > > > 1. Problem statement > -------------------- > > The current ASN assignment policy dictates two eligibility > criteria > and both should be fulfilled in order to get an ASN. The > policy > seems to imply that both requirements i.e. multi-homing and > clearly > defined single routing policy must be met simultaneously, > this has > created much confusion in interpreting the policy. > > As a result organizations have either provided incorrect > information > to get the ASN or barred themselves from applying. > > > 2. Objective of policy change > ----------------------------- > > In order to make the policy guidelines simpler we are > proposing to > modify the text describing the eligibility criteria for ASN > assignment by removing multi-homing requirement for the > organization. > > > 3. Situation in other regions > ----------------------------- > > ARIN: > It is not mandatory but optional to be multi-homed in order > get ASN > > RIPE: > Policy to remove multi-homing requirement is currently in > discussion > and the current phase ends 12 February 2015 > Policy - https://www.ripe.net/ripe/ > policies/proposals/2014-03 > > LACNIC: > only inter-connect is mandatory not multi-homing > > AFRINIC: > It is mandatory to be multi-homed in order to get ASN. > > > 4. Proposed policy solution > --------------------------- > > An organization is eligible for an ASN assignment if it: > - Is planning to use it within next 6 months > > > 5. Advantages / Disadvantages > ----------------------------- > > Advantages: > > Removing the mandatory multi-homing requirement from the > policy > will > make sure that organizations are not tempted to provide > wrong > information in order to fulfil the criteria of eligibility. > > Disadvantages: > > No disadvantage. > > > 6. Impact on resource holders > ----------------------------- > > No impact on existing resource holders. > > > 7. References > ------------- > > > > -- > -- > Dean Pemberton > > Technical Policy Advisor > InternetNZ > +64 21 920 363 (mob) > dean@internetnz.net.nz mailto:dean@internetnz.net.nz > > To promote the Internet's benefits and uses, and protect its > potential. > > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy > >
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Feb 23, 2015, at 13:34 , Dean Pemberton dean@internetnz.net.nz wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
For example, two or more ASNs that exchange peering on a private basis, but do not provide transit for each other.
There are other possible situations as well, this is just the simplest example.
There are players within the community who will significantly benefit from a policy framework with a reduced multi-homing and demonstrated needs requirement, but those entities are not necessarily the end LIRs.
More likely, they are end-user organizations rather than LIRs, but so what? Is there a reason not to serve end-user organizations or make their lives easier?
What these two proposals seek to do is remove all barriers to obtaining IPv4 addresses and ASNs.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
One of the major problems here is that the authors seek to do this one 'cut' at a time. Almost in an attempt to avoid waking the tiger which is ARIN's requirement for needs based allocation, or having the APNIC community discussion around 'needs based' allocation for IPv4 resources.
I don’t agree here. I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I would like to see us stop the subterfuge here.
I think that is an unfair accusation, even though I am not a supporter of the proposals as written.
I would support the ASN proposal if it were modified as I previously stated, to require either multihoming or a unique routing policy.
I will strongly report the removal of all conditions for the issuance of resources in any case. I would argue that if you’re going to make that claim and insist on discussing this under the terms of your proposed policy, that it is arguably equally dishonest not to include IPv6 in the list as well.
Owen
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming. If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
(http://en.wikipedia.org/wiki/Boiling_frog)
Dean
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
I¹m with Dean on both counts.
My opinion is, if you are buying a single homed transit + peering, you are multihoming.
However, if you are sub-allocated addresses from your upstream (non portable) + peering, you are doing something undesirable (in my personal opinion. Yours personal opinion may vary)
I think if you have a portable address block, and have demonstrated need for an ASN (hint: just say peering), then you should be able to get one or more (hint: just say discontiguous network) - which is not very different from the current policy.
On 25/2/15 5:02 am, "Dean Pemberton" dean@internetnz.net.nz wrote:
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute ³multihoming² in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid ³multihoming² whereupon I had to resort to ³a unique routing policy².
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I¹ve also encountered situations where this is considered ³not multihomed² and to be a ³unique routing policy².
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it¹s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don¹t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn¹t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I¹m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang =========
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Great - Thanks for that.
As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
I do not support the proposal
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On 25 February 2015 at 17:06, Dean Pemberton dean@internetnz.net.nz wrote:
Great - Thanks for that.
As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
I do not support the proposal
I concur with Dean - I don't see a requirement for this proposal, given the clarification of existing policy which has been provided, and thus do not support the proposal.
Dean Pemberton wrote on 25/02/2015 15:06 :
Great - Thanks for that.
As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
Same, I simply don't understand what problem is trying to be solved here.
If an organisation is connected to only one other organisation, there is no need for an ASN. If these two orgs want to use BGP, that's a private matter, and is what private ASNs are for - and there are now around 1 billion of those.
If an organisation needs to connect to at least two other ASNs, then they qualify under the APNIC definition which Guanliang shared.
philip --
I do not support the proposal
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A slight side tracking here - looking for some opinions.
how much of the cruft on IRR system is there because organizations with allocated prefixes have to depend on their upstreams for the creation of their route objects, which then doesn't get removed when the relationship ends.
- -gaurab
Please see my other email Phil.. there is very valid reasons for this policy change.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 4:25 PM, Philip Smith pfsinoz@gmail.com wrote:
Dean Pemberton wrote on 25/02/2015 15:06 :
Great - Thanks for that.
As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
Same, I simply don't understand what problem is trying to be solved here.
If an organisation is connected to only one other organisation, there is no need for an ASN. If these two orgs want to use BGP, that's a private matter, and is what private ASNs are for - and there are now around 1 billion of those.
If an organisation needs to connect to at least two other ASNs, then they qualify under the APNIC definition which Guanliang shared.
philip
I do not support the proposal
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of
multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS.
An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN
implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:
sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton
Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification
in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the
secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz
wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
> Firstly I agree with Randy here. If you're not multi-homed then
your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other
peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute
multihoming.
I agree, but it may not necessarily constitute “multihoming” in a
manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could
render this moot.
However, I have past experience where RIRs have rejected peerings with
related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve
also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal),
as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more
public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals
that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to
discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright
opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but
offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US
looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy*
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy*
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Nope - Your other email didn't provide any reasons which weren't covered by Philips answer.
If you have a peering session to two or more ASNs you are multihomed and you qualify. If you only peer with one ASN then you can do this with a private ASN. If you want to make a change and move from a single peer to more than one then you get quickly get an ASN. You can even get them in advance of a planned network change as seen in the current policy snippet below
"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)."
No need to change policy.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:09 PM, Skeeve Stevens skeeve@v4now.com wrote:
Please see my other email Phil.. there is very valid reasons for this policy change.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 4:25 PM, Philip Smith pfsinoz@gmail.com wrote:
Dean Pemberton wrote on 25/02/2015 15:06 :
Great - Thanks for that.
As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
Same, I simply don't understand what problem is trying to be solved here.
If an organisation is connected to only one other organisation, there is no need for an ASN. If these two orgs want to use BGP, that's a private matter, and is what private ASNs are for - and there are now around 1 billion of those.
If an organisation needs to connect to at least two other ASNs, then they qualify under the APNIC definition which Guanliang shared.
philip
I do not support the proposal
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of
multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS.
An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN
implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:
sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton
Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification
in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the
secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz
wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com
wrote:
>> Firstly I agree with Randy here. If you're not multi-homed then
your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
> > This is not true. > > You can be single homed to a single upstream, but, have other
peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
>
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute
multihoming.
I agree, but it may not necessarily constitute “multihoming” in a
manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could
render this moot.
However, I have past experience where RIRs have rejected peerings
with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve
also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
> While I oppose that (and thus completely oppose the other
proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more
public ASNs or via distinct circuits, etc.).
> I think it is more a case that smaller and simpler policy proposals
that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to
discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright
opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written,
but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US
looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy*
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy*
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Sorry Dean, I don't agree with you.
You guys are trying to tell people how to run their networks, and that they aren't allowed to pre-emptively design their connectivity to allow for changing to multi-homing, or away from it, without going through a change in network configuration.
That might be easy for you, but that is simply your opinion on how things should be done... not a reason why others shouldn't be allowed to do it the way they want to.
If a member has a portable range, they should be entitled to - with no restrictions - a ASN number to be able to BE as portable as they want to.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 5:20 PM, Dean Pemberton dean@internetnz.net.nz wrote:
Nope - Your other email didn't provide any reasons which weren't covered by Philips answer.
If you have a peering session to two or more ASNs you are multihomed and you qualify. If you only peer with one ASN then you can do this with a private ASN. If you want to make a change and move from a single peer to more than one then you get quickly get an ASN. You can even get them in advance of a planned network change as seen in the current policy snippet below
"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)."
No need to change policy.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:09 PM, Skeeve Stevens skeeve@v4now.com wrote:
Please see my other email Phil.. there is very valid reasons for this policy change.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 4:25 PM, Philip Smith pfsinoz@gmail.com wrote:
Dean Pemberton wrote on 25/02/2015 15:06 :
Great - Thanks for that.
As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
Same, I simply don't understand what problem is trying to be solved here.
If an organisation is connected to only one other organisation, there is no need for an ASN. If these two orgs want to use BGP, that's a private matter, and is what private ASNs are for - and there are now around 1 billion of those.
If an organisation needs to connect to at least two other ASNs, then they qualify under the APNIC definition which Guanliang shared.
philip
I do not support the proposal
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net
wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of
multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS.
An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate
ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:
sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton
Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114:
Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the
secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its
potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
> On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz
wrote:
> > On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com
wrote:
>>> Firstly I agree with Randy here. If you're not multi-homed then
your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
>> >> This is not true. >> >> You can be single homed to a single upstream, but, have other
peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
>> > > I don't agree (Damn and we were getting on so well this year =) ). > > I would argue that the situation you describe above DOES constitute
multihoming.
I agree, but it may not necessarily constitute “multihoming” in a
manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC
could render this moot.
However, I have past experience where RIRs have rejected peerings
with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
> If an LIR were connected to an upstream ISP but also wanted to > participate at an IXP I would consider them to be multihomed and > covered under existing APNIC policy.
What if they only connected to the IXP with a single connection?
I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
> > I couldn't find the strict definition on the APNIC pages as to what > the hostmasters considered multihoming to be, but if one of them can > point us to it then it might help.
Agreed.
> > >> While I oppose that (and thus completely oppose the other
proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
> > I really want to find out what those multi-homing requirements are. > I suspect that they amount to "BGP connections to two or more other > ASNs" > In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or
more public ASNs or via distinct circuits, etc.).
> > >> I think it is more a case that smaller and simpler policy
proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
> > I can see your point, but taking a smaller simpler approach is only > valid once you have agreed on the larger more strategic direction.
I
> don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to
discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
> We are seeing small proposals purporting to talk about multihoming, > but what they are in essence talking about is the much larger topic > of the removal of demonstrated need (as Aftab's clarification in the > other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to
outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written,
but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
> There is danger in the death by a thousand cuts. Many times you > can't see the unintended consequences until you are already down the > track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
> As we are in Japan I offer a haiku: > > A frog in water > doesn’t feel it boil in time. > Do not be that frog. > > (http://en.wikipedia.org/wiki/Boiling_frog)
I wish I could be at the meeting, but, alas, I’m here in the US
looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy*
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy*
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Feb 25, 2015, at 00:32 , Skeeve Stevens skeeve@v4now.com wrote:
Sorry Dean, I don't agree with you.
You guys are trying to tell people how to run their networks, and that they aren't allowed to pre-emptively design their connectivity to allow for changing to multi-homing, or away from it, without going through a change in network configuration.
That might be easy for you, but that is simply your opinion on how things should be done... not a reason why others shouldn't be allowed to do it the way they want to.
If a member has a portable range, they should be entitled to - with no restrictions - a ASN number to be able to BE as portable as they want to.
Even if I agreed with what you have said above, and I do not, this last statement bears no resemblence to the policy you have proposed.
If you want to propose a policy that matches your last sentence, I would not oppose that, so long as any additional ASNs had to be issued under the current multihome requirement.
However, your proposal doesn’t say someone who has PI space is entitled to 1 ASN. It says anyone who wants one is entitled to as many ASNs as they want.
That’s simply a bad idea.
Owen
Owen,
The intent is not to give people as many AS's as they want, and indeed few businesses would ever need more than 1 AS.
What about if businesses did not have the multi-homing requirement for the first ASN they were issued?
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:15 AM, Owen DeLong owen@delong.com wrote:
On Feb 25, 2015, at 00:32 , Skeeve Stevens skeeve@v4now.com wrote:
Sorry Dean, I don't agree with you.
You guys are trying to tell people how to run their networks, and that
they aren't allowed to pre-emptively design their connectivity to allow for changing to multi-homing, or away from it, without going through a change in network configuration.
That might be easy for you, but that is simply your opinion on how
things should be done... not a reason why others shouldn't be allowed to do it the way they want to.
If a member has a portable range, they should be entitled to - with no
restrictions - a ASN number to be able to BE as portable as they want to.
Even if I agreed with what you have said above, and I do not, this last statement bears no resemblence to the policy you have proposed.
If you want to propose a policy that matches your last sentence, I would not oppose that, so long as any additional ASNs had to be issued under the current multihome requirement.
However, your proposal doesn’t say someone who has PI space is entitled to 1 ASN. It says anyone who wants one is entitled to as many ASNs as they want.
That’s simply a bad idea.
Owen
On Feb 24, 2015, at 22:06 , Dean Pemberton dean@internetnz.net.nz wrote:
Great - Thanks for that.
As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114.
Agreed… However, it does allow one to basically get ASNs no matter what, since all one needs to do is cobble up 3 distinct sites and ask for an ASN for each site and then peer the sites with each other.
Owen
I do not support the proposal
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Thanks Guangliang for the update,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future?
Regards,
Aftab A. Siddiqui.
Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas.
It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies.
Regards, Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui aftab.siddiqui@gmail.com wrote:
Thanks Guangliang for the update,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future?
Regards,
Aftab A. Siddiqui.
To me, relaxing these rules is less about lying - although is easy, but it is to do with flexibility.
I understand the routing policy wont be different that an upstream without being multi-homed, but it does curtail the convenience of being able to add these things easily.
Lets say I was a company with a /23 and upstream into Telstra Only. If I had my own ASN and was announcing to Telstra, then at any time I could add another ISP, IXP, direct peering without having to go apply for an ASN, reconfigure my network to bring the announcement in-house, etc.
I also might want to maintain a single provider, but be able to migrate easily to another provider without having to rely on the providers to do the "right thing" while changing announcements between them.
I think this policy has VERY valid applications for many smaller entities to be able to have an ASN without having to be multi-homed either initially, or maintain that multi-homing.
As Randy used to say - Why do you have the right to tell me how to manage my network? If I want to be multi-homed, or change my mind and not be, it is none of your damn business.
I think this policy change reflects the changing way for businesses to get online since APNIC has run out of IP's, and are often charging significant amounts of money - so people are going to APNIC directly - which they are entitled to do. And being flexible and being able to change their circumstances is a more common thing nowadays.
If you want, suggest charging for ASN's... but don't tell networks how they should be connected at any time.
Btw... I am happy for this to apply ONLY to ASN4 and not ASN2.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 3:33 PM, Dean Pemberton dean@internetnz.net.nz wrote:
Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas.
It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies.
Regards, Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui aftab.siddiqui@gmail.com wrote:
Thanks Guangliang for the update,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It
is
also acceptable if your network only connect to an IXP.
So what if I only have one upstream provider and doesn't have a Public
IX in
place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email
notification
to those contacts provided in the application that XYZ has mentioned
your AS
to be peer with in future?
Regards,
Aftab A. Siddiqui.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Feb 24, 2015, at 22:46 , Skeeve Stevens skeeve@v4now.com wrote:
To me, relaxing these rules is less about lying - although is easy, but it is to do with flexibility.
I understand the routing policy wont be different that an upstream without being multi-homed, but it does curtail the convenience of being able to add these things easily.
Lets say I was a company with a /23 and upstream into Telstra Only. If I had my own ASN and was announcing to Telstra, then at any time I could add another ISP, IXP, direct peering without having to go apply for an ASN, reconfigure my network to bring the announcement in-house, etc.
No you can’t… You just have already done it instead of doing it when you get ready to actually multihome.
It’s all the same effort, just a difference in when you have to apply said effort.
I also might want to maintain a single provider, but be able to migrate easily to another provider without having to rely on the providers to do the "right thing" while changing announcements between them.
This has some validity, but if you have an overlap period, you’re multihomed during the overlap and eligible for an ASN as a result.
I think this policy has VERY valid applications for many smaller entities to be able to have an ASN without having to be multi-homed either initially, or maintain that multi-homing.
I don’t believe you lose your ASN if you stop multihoming.
As Randy used to say - Why do you have the right to tell me how to manage my network? If I want to be multi-homed, or change my mind and not be, it is none of your damn business.
That’s true. But nobody is trying to tell you that. I don’t believe the APNIC policy calls for reclaiming ASNs from entities that are no longer multihomed. It merely prevents issuing ASNs to entities that are not multihomed.
The only possible case I can see where this might be useful would be the case of two uplinks to the same ASN that are sufficiently topologically diverse as to make it desirable to do route injection for better failover capabilities.
I think this policy change reflects the changing way for businesses to get online since APNIC has run out of IP's, and are often charging significant amounts of money - so people are going to APNIC directly - which they are entitled to do. And being flexible and being able to change their circumstances is a more common thing nowadays.
No, this policy change turns APNIC into an ASN pez dispenser which is an undesirable state.
You don’t need an ASN to use provider independent addresses, so the rest of the paragraph is a red herring.
The flexibility exists. It’s just a question of when one does the work to turn on BGP and get an ASN. I see no reason the community should hand out ASNs to anyone who thinks they might want one for some possible use at some possible time in some possible future.
If you want, suggest charging for ASN's... but don't tell networks how they should be connected at any time.
Nobody is telling anyone how they should be connected. This is about resource management of a community resource pool, not about dictating operational practice. You can do everything you have said you want to do with your network under the existing policy. You just can’t get an ASN until you actually need one. Imagine where we’d be if we had handed out all the IPv4 space to anyone who thought they might need some someday?
Btw... I am happy for this to apply ONLY to ASN4 and not ASN2.
There are no more ASN4s than there are IPv4 addresses.
Owen
All,
I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree)
Currently they all have to "commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others.
Would we the proposal be acceptable if we reworded the proposal to say something on the lines of
³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²?
This would cover the use case without opening the floodgates.
Thoughts?
Raf
On 25/2/15 2:33 pm, "Dean Pemberton" dean@internetnz.net.nz wrote:
Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas.
It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies.
Regards, Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui aftab.siddiqui@gmail.com wrote:
Thanks Guangliang for the update,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future?
Regards,
Aftab A. Siddiqui.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Agreed... Aftabs use case is one of many... the others I just posted about.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 3:47 PM, Raphael Ho raphael.ho@ap.equinix.com wrote:
All,
I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree)
Currently they all have to "commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others.
Would we the proposal be acceptable if we reworded the proposal to say something on the lines of
³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²?
This would cover the use case without opening the floodgates.
Thoughts?
Raf
On 25/2/15 2:33 pm, "Dean Pemberton" dean@internetnz.net.nz wrote:
Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas.
It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies.
Regards, Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui aftab.siddiqui@gmail.com wrote:
Thanks Guangliang for the update,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future?
Regards,
Aftab A. Siddiqui.
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Feb 24, 2015, at 22:47 , Raphael Ho raphael.ho@ap.equinix.com wrote:
All,
I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree)
What is the disadvantage for them to get the ASN later, when they actually need it?
Currently they all have to "commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others.
They only have to commit fraud if they are determined to get an ASN before they need one.
Would we the proposal be acceptable if we reworded the proposal to say something on the lines of
³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²?
I think “an ASN” rather than “as ASN”, but I’d need to better understand why they need one ahead of time. What’s wrong with getting the ASN when you need it?
Owen
Owen,
But who determines 'if they need one' ? Them, or you (plural)?
I believe they should be able to determine that they need one and be able to get one based on that decision - not told how they should be doing their upstream connectivity at any particular time.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 22:47 , Raphael Ho raphael.ho@ap.equinix.com
wrote:
All,
I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree)
What is the disadvantage for them to get the ASN later, when they actually need it?
Currently they all have to "commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others.
They only have to commit fraud if they are determined to get an ASN before they need one.
Would we the proposal be acceptable if we reworded the proposal to say something on the lines of
³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²?
I think “an ASN” rather than “as ASN”, but I’d need to better understand why they need one ahead of time. What’s wrong with getting the ASN when you need it?
Owen
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Actually the RFC makes this clear.
There is clear guidance within RFC1930 for this which is marked as "BEST CURRENT PRACTICE". Please someone let me know if I've missed an obsolescence here.
All of the situations you are talking about are described as "rare and should almost never happen". If you believe that the RFC is wrong and no longer constitutes best practice, then engage in the IETF community and try and fix this at the source rather than using RIR policy to justify a departure from documented current best practice.
5.1 Sample Cases
* Single-homed site, single prefix
A separate AS is not needed; the prefix should be placed in an AS of the provider. The site's prefix has exactly the same rout- ing policy as the other customers of the site's service provider, and there is no need to make any distinction in rout- ing information.
This idea may at first seem slightly alien to some, but it high- lights the clear distinction in the use of the AS number as a representation of routing policy as opposed to some form of administrative use.
In some situations, a single site, or piece of a site, may find it necessary to have a policy different from that of its provider, or the rest of the site. In such an instance, a sepa- rate AS must be created for the affected prefixes. This situa- tion is rare and should almost never happen. Very few stub sites require different routing policies than their parents. Because the AS is the unit of policy, however, this sometimes occurs.
* Single-homed site, multiple prefixes
Again, a separate AS is not needed; the prefixes should be placed in an AS of the site's provider.
* Multi-homed site
Here multi-homed is taken to mean a prefix or group of prefixes which connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network multi-homed running an IGP for the purposes of resilience.
An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This allows the customer the ability to have a different repre- sentation of policy and preference among the different service providers.
This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens skeeve@v4now.com wrote:
Owen,
But who determines 'if they need one' ? Them, or you (plural)?
I believe they should be able to determine that they need one and be able to get one based on that decision - not told how they should be doing their upstream connectivity at any particular time.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 22:47 , Raphael Ho raphael.ho@ap.equinix.com
wrote:
All,
I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not
meet
the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree)
What is the disadvantage for them to get the ASN later, when they actually need it?
Currently they all have to "commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others.
They only have to commit fraud if they are determined to get an ASN before they need one.
Would we the proposal be acceptable if we reworded the proposal to say something on the lines of
³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²?
I think “an ASN” rather than “as ASN”, but I’d need to better understand why they need one ahead of time. What’s wrong with getting the ASN when you need it?
Owen
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Dean,
You are quoting an RFC from 1996 (19 years ago)? What next, the Old Testament? Thou shalt be multi-homed?
I don't think this RFC ever envisioned the IP runout and that networks hosted by businesses themselves (of any size) would need multi-homing and in the reading of this, you could make an argument that no-one needs an ASN and that all their upstreams could host their portable space for them.
Please understand, that I am not suggesting giving an ASN to anyone who has no intention of ever multi-homing.
I am wanting to policy to reflect that if a network operator wants to design their network for multi-homing, that they should be able to, with no requirement to immediately multi-home. At no point did I say 'never' multi-home, or no intention of multi-homing.... the intention should be there.
I'm asking that the policy reflect an operators choice to decide how they manage their networks should they choose to do it that way.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:36 AM, Dean Pemberton dean@internetnz.net.nz wrote:
Actually the RFC makes this clear.
There is clear guidance within RFC1930 for this which is marked as "BEST CURRENT PRACTICE". Please someone let me know if I've missed an obsolescence here.
All of the situations you are talking about are described as "rare and should almost never happen". If you believe that the RFC is wrong and no longer constitutes best practice, then engage in the IETF community and try and fix this at the source rather than using RIR policy to justify a departure from documented current best practice.
5.1 Sample Cases
Single-homed site, single prefix
A separate AS is not needed; the prefix should be placed in an AS of the provider. The site's prefix has exactly the same rout- ing policy as the other customers of the site's service provider, and there is no need to make any distinction in rout- ing information.
This idea may at first seem slightly alien to some, but it high- lights the clear distinction in the use of the AS number as a representation of routing policy as opposed to some form of administrative use.
In some situations, a single site, or piece of a site, may find it necessary to have a policy different from that of its provider, or the rest of the site. In such an instance, a sepa- rate AS must be created for the affected prefixes. This situa- tion is rare and should almost never happen. Very few stub sites require different routing policies than their parents. Because the AS is the unit of policy, however, this sometimes occurs.
Single-homed site, multiple prefixes
Again, a separate AS is not needed; the prefixes should be placed in an AS of the site's provider.
Multi-homed site
Here multi-homed is taken to mean a prefix or group of prefixes which connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network multi-homed running an IGP for the purposes of resilience.
An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This allows the customer the ability to have a different repre- sentation of policy and preference among the different service providers.
This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens skeeve@v4now.com wrote:
Owen,
But who determines 'if they need one' ? Them, or you (plural)?
I believe they should be able to determine that they need one and be able to get one based on that decision - not told how they should be doing their upstream connectivity at any particular time.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 22:47 , Raphael Ho raphael.ho@ap.equinix.com
wrote:
All,
I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not
meet
the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree)
What is the disadvantage for them to get the ASN later, when they actually need it?
Currently they all have to "commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others.
They only have to commit fraud if they are determined to get an ASN before they need one.
Would we the proposal be acceptable if we reworded the proposal to say something on the lines of
³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²?
I think “an ASN” rather than “as ASN”, but I’d need to better understand why they need one ahead of time. What’s wrong with getting the ASN when you need it?
Owen
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens skeeve@v4now.com wrote:
I'm asking that the policy reflect an operators choice to decide how they manage their networks should they choose to do it that way.
I believe we've entered the point of diminishing returns here.
It has been shown multiple times in this thread that there is no barrier to getting an ASN if one is required under the current policy. This fact has been supported by the current hostmasters. Operators currently have the freedom to choose how to manage their networks, they can choose to get an ASN anytime they need one for operational purposes.
There is no change in policy required.
I strongly oppose this policy as written.
Dean,
What you are saying is your rose coloured view of this.
"You say they can get an ASN anytime they need one for operation purposes". I am saying that the case exists that operators will want to do this - WITHOUT the requirement for being multi-homed.
The requirement for being multi-homed, 'as written' causes members to either lie to provide false information or find a way around the restriction (using HE or someone else) to choose how they wish to manage their network.
You choosing to ignore this use case or situation doesn't make it go away because you don't understand why they would want to manage their network in that way.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:55 AM, Dean Pemberton dean@internetnz.net.nz wrote:
On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens skeeve@v4now.com wrote:
I'm asking that the policy reflect an operators choice to decide how they manage their networks should they choose to do it that way.
I believe we've entered the point of diminishing returns here.
It has been shown multiple times in this thread that there is no barrier to getting an ASN if one is required under the current policy. This fact has been supported by the current hostmasters. Operators currently have the freedom to choose how to manage their networks, they can choose to get an ASN anytime they need one for operational purposes.
There is no change in policy required.
I strongly oppose this policy as written.
While I tend to agree that the current draft policy in its form needs more work, I empathize with the long-held concern of detachment between the RIR and network operations. This is a well-documented issue that affects several other policies within various RIR communities, and not just this one nor APNIC. Take assigned prefix length and what operators filter against as an example.
Globally, perhaps we would do well to find way to make RIR operations and policy design reflect the practical day-to-day changes taking place within operator networks, or at the very least, make a provision for them that sufficiently covers what the future may throw up.
I don't think any of us have the answers now, but it starts from somewhere.
Mark.
In theory, this is why each RIR has a public policy process open to any who choose to participate.
The fact that operator participation in the process is limited (voluntarily by the operators themselves) continues to cause problems for operators. This not only affects RIRs, but also the IETF, ICANN, and other multi-stakeholder fora covering various aspects of internet governance and development.
If you have a suggestion for getting greater operator participation in these processes, I’m all ears.
Owen
On Feb 25, 2015, at 5:27 PM, Mark Tinka mark.tinka@seacom.mu wrote:
While I tend to agree that the current draft policy in its form needs more work, I empathize with the long-held concern of detachment between the RIR and network operations. This is a well-documented issue that affects several other policies within various RIR communities, and not just this one nor APNIC. Take assigned prefix length and what operators filter against as an example.
Globally, perhaps we would do well to find way to make RIR operations and policy design reflect the practical day-to-day changes taking place within operator networks, or at the very least, make a provision for them that sufficiently covers what the future may throw up.
I don't think any of us have the answers now, but it starts from somewhere.
Mark.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Feb 25, 2015, at 15:50 , Skeeve Stevens skeeve@v4now.com wrote:
Dean,
You are quoting an RFC from 1996 (19 years ago)? What next, the Old Testament? Thou shalt be multi-homed?
I don't think this RFC ever envisioned the IP runout and that networks hosted by businesses themselves (of any size) would need multi-homing and in the reading of this, you could make an argument that no-one needs an ASN and that all their upstreams could host their portable space for them.
IP runout was well and truly known to be coming more than 20 years ago. That’s one of the reasons IPv6 was developed so long ago.
Please understand, that I am not suggesting giving an ASN to anyone who has no intention of ever multi-homing.
Yes you are. You may not intend to suggest that, but your policy proposal wording certainly provides for it.
I am wanting to policy to reflect that if a network operator wants to design their network for multi-homing, that they should be able to, with no requirement to immediately multi-home. At no point did I say 'never' multi-home, or no intention of multi-homing.... the intention should be there.
Then propose a policy that does that. The current draft doesn’t. If it has sufficient safeguards against turning the ASN registry into a Pez dispenser, then I will support it.
I'm asking that the policy reflect an operators choice to decide how they manage their networks should they choose to do it that way.
Nobody is objecting to that. However, that’s not a letter of the law interpretation of what you have proposed.
Owen
...Skeeve
Skeeve Stevens - Senior IP Broker v4Now - an eintellego Networks service skeeve@v4now.com mailto:skeeve@v4now.com ; www.v4now.com http://www.v4now.com/ Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <> facebook.com/v4now http://facebook.com/v4now ; http://twitter.com/networkceoaulinkedin.com/in/skeeve http://linkedin.com/in/skeeve twitter.com/theispguy http://twitter.com/theispguy ; blog: www.theispguy.com http://www.theispguy.com/
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:36 AM, Dean Pemberton <dean@internetnz.net.nz mailto:dean@internetnz.net.nz> wrote: Actually the RFC makes this clear.
There is clear guidance within RFC1930 for this which is marked as "BEST CURRENT PRACTICE". Please someone let me know if I've missed an obsolescence here.
All of the situations you are talking about are described as "rare and should almost never happen". If you believe that the RFC is wrong and no longer constitutes best practice, then engage in the IETF community and try and fix this at the source rather than using RIR policy to justify a departure from documented current best practice.
5.1 Sample Cases
Single-homed site, single prefix
A separate AS is not needed; the prefix should be placed in an AS of the provider. The site's prefix has exactly the same rout- ing policy as the other customers of the site's service provider, and there is no need to make any distinction in rout- ing information.
This idea may at first seem slightly alien to some, but it high- lights the clear distinction in the use of the AS number as a representation of routing policy as opposed to some form of administrative use.
In some situations, a single site, or piece of a site, may find it necessary to have a policy different from that of its provider, or the rest of the site. In such an instance, a sepa- rate AS must be created for the affected prefixes. This situa- tion is rare and should almost never happen. Very few stub sites require different routing policies than their parents. Because the AS is the unit of policy, however, this sometimes occurs.
Single-homed site, multiple prefixes
Again, a separate AS is not needed; the prefixes should be placed in an AS of the site's provider.
Multi-homed site
Here multi-homed is taken to mean a prefix or group of prefixes which connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network multi-homed running an IGP for the purposes of resilience.
An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This allows the customer the ability to have a different repre- sentation of policy and preference among the different service providers.
This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens <skeeve@v4now.com mailto:skeeve@v4now.com> wrote: Owen,
But who determines 'if they need one' ? Them, or you (plural)?
I believe they should be able to determine that they need one and be able to get one based on that decision - not told how they should be doing their upstream connectivity at any particular time.
...Skeeve
Skeeve Stevens - Senior IP Broker v4Now - an eintellego Networks service skeeve@v4now.com mailto:skeeve@v4now.com ; www.v4now.com http://www.v4now.com/ Phone: 1300 239 038; Cell +61 (0)414 753 383 tel:%2B61%20%280%29414%20753%20383 ; skype://skeeve <> facebook.com/v4now http://facebook.com/v4now ; http://twitter.com/networkceoaulinkedin.com/in/skeeve http://linkedin.com/in/skeeve twitter.com/theispguy http://twitter.com/theispguy ; blog: www.theispguy.com http://www.theispguy.com/
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong <owen@delong.com mailto:owen@delong.com> wrote:
On Feb 24, 2015, at 22:47 , Raphael Ho <raphael.ho@ap.equinix.com mailto:raphael.ho@ap.equinix.com> wrote:
All,
I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree)
What is the disadvantage for them to get the ASN later, when they actually need it?
Currently they all have to "commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others.
They only have to commit fraud if they are determined to get an ASN before they need one.
Would we the proposal be acceptable if we reworded the proposal to say something on the lines of
³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²?
I think “an ASN” rather than “as ASN”, but I’d need to better understand why they need one ahead of time. What’s wrong with getting the ASN when you need it?
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net mailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net mailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Aftab, If a network is single homed, according to the current policy, it does not qualify for a public ASN assignment. We would recommend requestors to use a private ASN instead. – I believe this is the main debate point of this policy discussion.
APNIC Members are bound by the membership agreement to not provide false or misleading information in their resource application. We work on the basis of trust when we do our evaluations. However, Hostmasters do contact other ASN peers if necessary to verify information provided in the request. The ASN policy doesn’t request APNIC to monitor the ASN peering. APNIC Members are allowed to change their network peers at any time. The aut-num object in the whois database is maintained by the Member’s maintainer, and it is their responsibility to update their peer information in a timely manner. Best regards, Guangliang =========
From: Aftab Siddiqui [mailto:aftab.siddiqui@gmail.com] Sent: Wednesday, 25 February 2015 4:25 PM To: Guangliang Pan Cc: Dean Pemberton; Owen DeLong; sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Thanks Guangliang for the update,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future?
Regards,
Aftab A. Siddiqui.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Guangliang,
can you clarify these questions for me.
If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ?
- -gaurab
On 2/25/15 4:05 AM, Guangliang Pan wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang =========
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy- _______________________________________________ sig-policy
mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
- --
I would think it would... why does it matter how you get to another peer?
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 5:09 PM, Gaurab Raj Upadhaya gaurab@lahai.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Guangliang,
can you clarify these questions for me.
If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ?
- -gaurab
On 2/25/15 4:05 AM, Guangliang Pan wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang =========
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy- _______________________________________________ sig-policy
mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlTtg1QACgkQSo7fU26F3X3nSACfZayuWmeykSI2WzjhOZ0AO9rY I+kAoM863V5skin8wC/7sYaFfmhpwiTu =YRGr -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Gaurab,
If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment.
Regards, Guangliang
On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya" gaurab@lahai.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Guangliang,
can you clarify these questions for me.
If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ?
- -gaurab
On 2/25/15 4:05 AM, Guangliang Pan wrote: Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang =========
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy- _______________________________________________ sig-policy
mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlTtg1QACgkQSo7fU26F3X3nSACfZayuWmeykSI2WzjhOZ0AO9rY I+kAoM863V5skin8wC/7sYaFfmhpwiTu =YRGr -----END PGP SIGNATURE-----
Guangliang,
What are the rules about someone with a ASN, later de-multi-homing?
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 6:53 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Gaurab,
If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment.
Regards, Guangliang
On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya" gaurab@lahai.com
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Guangliang,
can you clarify these questions for me.
If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ?
- -gaurab
On 2/25/15 4:05 AM, Guangliang Pan wrote: Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang =========
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
> Firstly I agree with Randy here. If you're not multi-homed > then your routing policy can not be 'unique' from your > single upstream. You may wish it was, but you have no way > to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy- _______________________________________________ sig-policy
mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlTtg1QACgkQSo7fU26F3X3nSACfZayuWmeykSI2WzjhOZ0AO9rY I+kAoM863V5skin8wC/7sYaFfmhpwiTu =YRGr -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Skeeve,
I don't think we have a policy to reclaim those AS Numbers.
Regards, Guangliang
On 25 Feb 2015, at 7:57 pm, "Skeeve Stevens" <skeeve@v4now.commailto:skeeve@v4now.com> wrote:
Guangliang,
What are the rules about someone with a ASN, later de-multi-homing?
...Skeeve
Skeeve Stevens - Senior IP Broker v4Now - an eintellego Networks service skeeve@v4now.commailto:skeeve@v4now.com ; www.v4now.comhttp://www.v4now.com/
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4nowhttp://facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeevehttp://linkedin.com/in/skeeve
twitter.com/theispguyhttp://twitter.com/theispguy ; blog: www.theispguy.comhttp://www.theispguy.com/
[http://eintellegonetworks.com/logos/v4now-web05.png]
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 6:53 PM, Guangliang Pan <gpan@apnic.netmailto:gpan@apnic.net> wrote: Hi Gaurab,
If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment.
Regards, Guangliang
On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya" <gaurab@lahai.commailto:gaurab@lahai.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Guangliang,
can you clarify these questions for me.
If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ?
- -gaurab
On 2/25/15 4:05 AM, Guangliang Pan wrote: Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang =========
-----Original Message----- From: sig-policy-bounces@lists.apnic.netmailto:sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.netmailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.netmailto:sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nzmailto:dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong <owen@delong.commailto:owen@delong.com> wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton <dean@internetnz.net.nzmailto:dean@internetnz.net.nz> wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong <owen@delong.commailto:owen@delong.com> wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy- _______________________________________________ sig-policy
mailing list sig-policy@lists.apnic.netmailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.netmailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlTtg1QACgkQSo7fU26F3X3nSACfZayuWmeykSI2WzjhOZ0AO9rY I+kAoM863V5skin8wC/7sYaFfmhpwiTu =YRGr -----END PGP SIGNATURE-----
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.netmailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Thanks for that Guangliang. Thats really helped to clarify the position here.
Another question. Whats the normal time lag between a member applying for an ASN (assuming that all the information is present and correct) and it being allocated?
1 day? 1 week? 1 month?
I'm trying to gauge if it really takes longer to apply for an ASN than it does to arrange and configure a BGP peering session.
Thanks Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Dean,
I'm not debating the time it takes to get an ASN allocated... I'm talking about everything else around it... and changing your setup when you shouldn't even have to... again, you're telling people how to run their networks.
I'm simply saying that leave the running of the networks to them... let them decide when, if they multi-home, if they choose to de-multi-home, etc.
We all know we can lie our way around this... but people shouldn't have to... and if that is the only reason, then it is still a valid one.
A rule that isn't enforced, or has any repercussions for going around, shouldn't even be there in the first place. If the only reason it remains is to annoy some small number of ethical people, it should be remediated.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 25, 2015 at 5:35 PM, Dean Pemberton dean@internetnz.net.nz wrote:
Thanks for that Guangliang. Thats really helped to clarify the position here.
Another question. Whats the normal time lag between a member applying for an ASN (assuming that all the information is present and correct) and it being allocated?
1 day? 1 week? 1 month?
I'm trying to gauge if it really takes longer to apply for an ASN than it does to arrange and configure a BGP peering session.
Thanks Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean and All,
According to the current APNIC ASN policy document, the definition of
multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An
AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN
implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:
sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton
Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification
in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the
secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz
wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then
your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering
relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute
multihoming.
I agree, but it may not necessarily constitute “multihoming” in a
manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could
render this moot.
However, I have past experience where RIRs have rejected peerings with
related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve
also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal),
as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more
public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals
that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to
discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright
opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but
offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking
on from afar.
Owen
sig-policy: APNIC SIG on resource management policy*
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Dean,
If they meet the policy requirement and no payment requested, they normally will receive an ASN in the next working day.
Thanks, Guangliang
On 25 Feb 2015, at 6:36 pm, "Dean Pemberton" dean@internetnz.net.nz wrote:
Thanks for that Guangliang. Thats really helped to clarify the position here.
Another question. Whats the normal time lag between a member applying for an ASN (assuming that all the information is present and correct) and it being allocated?
1 day? 1 week? 1 month?
I'm trying to gauge if it really takes longer to apply for an ASN than it does to arrange and configure a BGP peering session.
Thanks Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote: Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Thanks Guangliang,
That's what I hoped the answer would be and it's great to see that the hostmasters are able to turn these around so quickly.
My summary here after all we have discussed is that under the current policy, if there is an operational need (connecting to more than one ASN or to an IXP) for a member to have an ASN, they can apply a short time in advance and generally receive an ASN the next working day.
There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that.
Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 10:36 PM, Guangliang Pan gpan@apnic.net wrote:
Hi Dean,
If they meet the policy requirement and no payment requested, they normally will receive an ASN in the next working day.
Thanks, Guangliang
On 25 Feb 2015, at 6:36 pm, "Dean Pemberton" dean@internetnz.net.nz wrote:
Thanks for that Guangliang. Thats really helped to clarify the position here.
Another question. Whats the normal time lag between a member applying for an ASN (assuming that all the information is present and correct) and it being allocated?
1 day? 1 week? 1 month?
I'm trying to gauge if it really takes longer to apply for an ASN than it does to arrange and configure a BGP peering session.
Thanks Dean -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan gpan@apnic.net wrote: Hi Dean and All,
According to the current APNIC ASN policy document, the definition of multihomed is as below.
http://www.apnic.net/policy/asn-policy#3.4
3.4 Multihomed
A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point.
In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP.
Best regards,
Guangliang
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here.
-- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong owen@delong.com wrote:
On Feb 24, 2015, at 12:38 , Dean Pemberton dean@internetnz.net.nz wrote:
On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong owen@delong.com wrote:
> Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this.
This is not true.
You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation.
I don't agree (Damn and we were getting on so well this year =) ).
I would argue that the situation you describe above DOES constitute multihoming.
I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR.
Clarification from APNIC staff on the exact behavior from APNIC could render this moot.
However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”.
If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy.
What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”.
I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help.
Agreed.
While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective.
I really want to find out what those multi-homing requirements are. I suspect that they amount to "BGP connections to two or more other ASNs" In which case I think we can go back to agreeing.
As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.).
I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity.
I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations.
I find that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
YMMV.
We are seeing small proposals purporting to talk about multihoming, but what they are in essence talking about is the much larger topic of the removal of demonstrated need (as Aftab's clarification in the other thread confirms beyond doubt.)
Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
There is danger in the death by a thousand cuts. Many times you can't see the unintended consequences until you are already down the track of smaller simpler policy changes.
I really don’t think that is a risk in this case.
As we are in Japan I offer a haiku:
A frog in water doesn’t feel it boil in time. Do not be that frog.
I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On 2/25/15 15:44 , Dean Pemberton wrote: ...
There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that.
Dean
From a policy perspective there is no barrier to entry.
However, from an operational perspective, I see it a little differently; having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN. Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX. If I'm a small network, this may not be a big hardship. But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated.
I'm not sure that justifies obliterating the current policy, but there is at least an operational barrier to entry in some situations. I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX.
A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line.
David,
I agree very much with the operational perspective (obviously), but since when in this day and age of infrastructure that size still matters?
Having to change your infrastructure (of any size), potentially with outages and so on, is not acceptable if you are able to design around it from day one.
I see it enough that a member should be able to proactively design their connectivity (should they want to - no one is being forced here) to have the potential for multi-homing.
The silly thing with the multi-homing barrier as Guangliang confirmed, you could multi-home for 1 day and meet the criteria and then disconnect and then you are still allowed to continue using it. So why have the restriction there in the first place?
Surely if someone thinks having an ASN is important in their design, they should be allowed to have one.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:10 AM, David Farmer farmer@umn.edu wrote:
On 2/25/15 15:44 , Dean Pemberton wrote: ...
There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that.
Dean
From a policy perspective there is no barrier to entry.
However, from an operational perspective, I see it a little differently; having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN. Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX. If I'm a small network, this may not be a big hardship. But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated.
I'm not sure that justifies obliterating the current policy, but there is at least an operational barrier to entry in some situations. I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX.
A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line.
--
David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Feb 25, 2015, at 15:10 , David Farmer farmer@umn.edu wrote:
On 2/25/15 15:44 , Dean Pemberton wrote: ...
There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that.
Dean
From a policy perspective there is no barrier to entry.
However, from an operational perspective, I see it a little differently; having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN. Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX. If I'm a small network, this may not be a big hardship. But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated.
That’s actually not the case.
The case is until you choose to multihome or connect to an IX. You can choose to do that with a pretty small network. My home is multihomed, for example.
Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on BGP, and poof, they are sufficiently multihomed for the APNIC definition. HE has several tunnel servers in the APNIC region to support this.
Changing ASNs on peering sessions actually isn’t very hard. There’s a brief period where you have inconsistent origin, but otherwise, it’s mostly one line of config change on each of your border routers. Even if you’ve got a hundred peering sessions, it’s something that can be done in a day or two with a cooperative provider. It might take a few weeks with some of the less responsive providers.
However, while I’m not trying to tell anyone how to run their network, I think we can agree that it is pretty foolhearty to get much beyond 2 or 3 peering sessions without mixing in some provider diversity. Further, if you want to plan ahead and deploy an ASN early, turning up an HE tunnel to do that is pretty easy. Unless HE is your only upstream for IPv4, you’re all set at that point.
I'm not sure that justifies obliterating the current policy, but there is at least an operational barrier to entry in some situations. I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX.
I don’t think size is relevant. As I said, I wouldn’t oppose a policy modification that in addition to the current mechanisms, allowed for anyone with a PI allocation or assignment to obtain a single ASN without question.
A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line.
I’m having trouble envisioning who would build a network with 100 border routers (only the border routers really count in this case) without connecting to more than one upstream. This smells like looking for a corner case to justify a solution looking for a problem statement.
Owen
Owen,
Can't you see the fault in your argument? You are suggesting that a member needlessly creates a tunnel to HE just to satisfy the needs of the current policy... that seems wasteful and a stupid hoop which just gets around the policy.
I might as well just offer free peering with a couple of routes to my ASN for anyone who wants to satisfy the policy.
The point here is fixing a requirement that is so easily avoided, it needed be there in the first place.
All you are doing is causing people to create route-object garbage so that they are able to run their networks the way they want to.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:26 AM, Owen DeLong owen@delong.com wrote:
On Feb 25, 2015, at 15:10 , David Farmer farmer@umn.edu wrote:
On 2/25/15 15:44 , Dean Pemberton wrote: ...
There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that.
Dean
From a policy perspective there is no barrier to entry.
However, from an operational perspective, I see it a little differently;
having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN. Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX. If I'm a small network, this may not be a big hardship. But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated.
That’s actually not the case.
The case is until you choose to multihome or connect to an IX. You can choose to do that with a pretty small network. My home is multihomed, for example.
Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on BGP, and poof, they are sufficiently multihomed for the APNIC definition. HE has several tunnel servers in the APNIC region to support this.
Changing ASNs on peering sessions actually isn’t very hard. There’s a brief period where you have inconsistent origin, but otherwise, it’s mostly one line of config change on each of your border routers. Even if you’ve got a hundred peering sessions, it’s something that can be done in a day or two with a cooperative provider. It might take a few weeks with some of the less responsive providers.
However, while I’m not trying to tell anyone how to run their network, I think we can agree that it is pretty foolhearty to get much beyond 2 or 3 peering sessions without mixing in some provider diversity. Further, if you want to plan ahead and deploy an ASN early, turning up an HE tunnel to do that is pretty easy. Unless HE is your only upstream for IPv4, you’re all set at that point.
I'm not sure that justifies obliterating the current policy, but there
is at least an operational barrier to entry in some situations. I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX.
I don’t think size is relevant. As I said, I wouldn’t oppose a policy modification that in addition to the current mechanisms, allowed for anyone with a PI allocation or assignment to obtain a single ASN without question.
A network of 1 or 2 routers probably doesn't justify an ASN unless it is
multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line.
I’m having trouble envisioning who would build a network with 100 border routers (only the border routers really count in this case) without connecting to more than one upstream. This smells like looking for a corner case to justify a solution looking for a problem statement.
Owen
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Feb 25, 2015, at 15:36 , Skeeve Stevens skeeve@v4now.com wrote:
Owen,
Can't you see the fault in your argument? You are suggesting that a member needlessly creates a tunnel to HE just to satisfy the needs of the current policy... that seems wasteful and a stupid hoop which just gets around the policy.
Who said anything about needlessly… They probably need IPv6 and this gets them decent IPv6 connectivity.
I might as well just offer free peering with a couple of routes to my ASN for anyone who wants to satisfy the policy.
You’re certainly welcome to do that. After all, I’m not trying to tell you how to run your network.
The point here is fixing a requirement that is so easily avoided, it needed be there in the first place.
But you go so far beyond fixing the requirement that you break so much more. Go back and look at what I said about a policy I would not object to.
All you are doing is causing people to create route-object garbage so that they are able to run their networks the way they want to.
I didn’t say anything about creating a single route object. There’s no requirement to create a route object or even use an IRR in anything I said, so you’re just wrong here.
Owen
...Skeeve
Skeeve Stevens - Senior IP Broker v4Now - an eintellego Networks service skeeve@v4now.com mailto:skeeve@v4now.com ; www.v4now.com http://www.v4now.com/ Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <> facebook.com/v4now http://facebook.com/v4now ; http://twitter.com/networkceoaulinkedin.com/in/skeeve http://linkedin.com/in/skeeve twitter.com/theispguy http://twitter.com/theispguy ; blog: www.theispguy.com http://www.theispguy.com/
IP Address Brokering - Introducing sellers and buyers
On Thu, Feb 26, 2015 at 8:26 AM, Owen DeLong <owen@delong.com mailto:owen@delong.com> wrote:
On Feb 25, 2015, at 15:10 , David Farmer <farmer@umn.edu mailto:farmer@umn.edu> wrote:
On 2/25/15 15:44 , Dean Pemberton wrote: ...
There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that.
Dean
From a policy perspective there is no barrier to entry.
However, from an operational perspective, I see it a little differently; having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN. Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX. If I'm a small network, this may not be a big hardship. But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated.
That’s actually not the case.
The case is until you choose to multihome or connect to an IX. You can choose to do that with a pretty small network. My home is multihomed, for example.
Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on BGP, and poof, they are sufficiently multihomed for the APNIC definition. HE has several tunnel servers in the APNIC region to support this.
Changing ASNs on peering sessions actually isn’t very hard. There’s a brief period where you have inconsistent origin, but otherwise, it’s mostly one line of config change on each of your border routers. Even if you’ve got a hundred peering sessions, it’s something that can be done in a day or two with a cooperative provider. It might take a few weeks with some of the less responsive providers.
However, while I’m not trying to tell anyone how to run their network, I think we can agree that it is pretty foolhearty to get much beyond 2 or 3 peering sessions without mixing in some provider diversity. Further, if you want to plan ahead and deploy an ASN early, turning up an HE tunnel to do that is pretty easy. Unless HE is your only upstream for IPv4, you’re all set at that point.
I'm not sure that justifies obliterating the current policy, but there is at least an operational barrier to entry in some situations. I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX.
I don’t think size is relevant. As I said, I wouldn’t oppose a policy modification that in addition to the current mechanisms, allowed for anyone with a PI allocation or assignment to obtain a single ASN without question.
A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line.
I’m having trouble envisioning who would build a network with 100 border routers (only the border routers really count in this case) without connecting to more than one upstream. This smells like looking for a corner case to justify a solution looking for a problem statement.
Owen
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net mailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy http://mailman.apnic.net/mailman/listinfo/sig-policy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2/25/15 11:10 PM, David Farmer wrote:
A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line.
even more slippery slope. eg. AS 29216 has a single upstream, with just 2 prefixes (one v4, one v6). and they have a legitimate need, so size is irrelevant.
- -gaurab
On Thu, Feb 26, 2015 at 03:08:42PM +0000, Gaurab Raj Upadhaya wrote:
On 2/25/15 11:10 PM, David Farmer wrote:
A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line.
even more slippery slope. eg. AS 29216 has a single upstream, with just 2 prefixes (one v4, one v6). and they have a legitimate need, so size is irrelevant.
I agree with Gaurab, attempting to pinpoint where to draw the line in this context is not worth the effort. Talking about 'size', assumes networks can be classified by quantitative metrics.
On Tue, Feb 03, 2015 at 11:57:38AM -0600, Masato Yamanishi wrote:
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?
I support this proposal. I appreciate its simplicity.
Kind regards,
Job
I support this proposal as well.
Regards, Usman
From: Job Snijders job@instituut.net To: Masato Yamanishi myamanis@gmail.com Cc: sig-policy@lists.apnic.net Sent: Wednesday, 4 February 2015, 7:19 Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On Tue, Feb 03, 2015 at 11:57:38AM -0600, Masato Yamanishi wrote:
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?
I support this proposal. I appreciate its simplicity.
Kind regards,
Job * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
In order to make the policy guidelines simpler we are proposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization. An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months
planning to use it as what? a guess in the lucky numbers draw?
on the global net, as numbers are for autonomous systems, i.e. those whose routing policies differ from their neighbor, see rfc1930. unless you are multi-homed, your policy can not differ from that of your neighbor (== upstream).
so the little hack above should be
- Is planning to use it within next 6 months
^ for multi-homing
randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2/3/15 9:19 PM, Randy Bush wrote:
so the little hack above should be
- Is planning to use it within next 6 months
^ for multi-homing
make it applicable only for 32 bits ASNs.
(duck)
- -gaurab
i liked dean's question. is there actually a problem? have folk who really needed asns not been able to get one under current policy?
randy, thinking of reintroducing the no more policies policy proposal
Hi Randy,
i liked dean's question. is there actually a problem? have folk who
really needed asns not been able to get one under current policy?
Even, I liked Dean's question and would like to see what data hostmasters have on this.
randy, thinking of reintroducing the no more policies policy proposal.
I would love to see prop-108 again :)
I did actually think that... but Aftab rightly pointed out that there are people who still can use them, due to their own equipment or due to their upstreams.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Feb 4, 2015 at 1:21 PM, Gaurab Raj Upadhaya gaurab@lahai.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2/3/15 9:19 PM, Randy Bush wrote:
so the little hack above should be
- Is planning to use it within next 6 months
^ for multi-homing
make it applicable only for 32 bits ASNs.
(duck)
- -gaurab
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlTRgkAACgkQSo7fU26F3X3BnACaA/cWeaPosz/0m4Oh9rCkS8Qc PHkAn1QaM551nYWJojMBVjNpeR/LyRET =Ad7X -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
- Situation in other regions
ARIN: It is not mandatory but optional to be multi-homed in order get ASN
For clarity, ARIN requires either Multihoming _OR_ a Unique Routing Policy.
- Proposed policy solution
An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months
I’d like to see something more stringent than this. This amounts to a Pez dispenser for ASNs.
I can claim I plan to do just about anything within 6 months.
Is there a problem with preserving the existing policy and simply clarifying that either of the two requirements being satisfied is sufficient?
That is, match the ARIN policy of Multihoming _OR_ a Unique Routing Policy?
- Advantages / Disadvantages
Advantages:
Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility.Disadvantages:
No disadvantage.
I disagree. I think putting ASNs into a Pez dispenser has numerous disadvantages.
While there are 4 billion ASNs, as we have seen demonstrated before, 4 billion is still a finite number.
Owen
I support the concept that AS number allocation rules should be relaxed, but I think further work is required to properly define the residual criteria for allocation.
Having read the past month's discussion about prop-114, I'll make some observations:
Let's not treat 4 billion (4-byte) AS numbers as precious. They're only route attributes, and not actual routes, and they can only be used with BGP routing, so their utility is high restricted, and their potential for direct abuse limited. (Large numbers of AS numbers by themselves don't explode routing tables, for example.)
If we consume 10,000 per year globally, then it will be 400,000 years before we exhaust the space - so I think we can afford some waste. We also only allocate AS numbers as individual numbers, and not as blocks of thousands or millions in the way we did for IPv4, and so greatly reducing the chance for massive waste.
We could argue back and forth what constitutes "appropriate" use of an AS number, but I see limited value in doing so given the enormous space now available (for 4-byte ASs); I feel the pragmatics outweigh the principles here.
I therefore believe it is not worth the Hostmasters' time (and therefore the members' money) to make onerous checks on whether AS numbers are being or will be used in a "suitable" way. I'd rather see fees charged to put the onus on the requester to decide whether they really needed the AS. A cap on the number of ASs per account could also be imposed if considered warranted.
So I feel that: - 4-byte ASs should simply be allocated upon request, with existing checks removed;
- Reasonable annual fees (for example, $ per AS per year) could be charged as a disincentive for frivolous requests.
- Or a cap could be imposed on the number of AS numbers allocated per account;
- Or a combination of cap and charging; for example, up to xx ASs per account are free, and then each additional AS will be charged at $yy per AS per year.
- Existing constraints should remain for 2-byte ASs
Regards,
David Woodgate
On 4/02/2015 4:57 AM, Masato Yamanishi wrote:
Dear SIG members
The proposal "prop-114: Modification in the ASN eligibility criteria" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015.
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-114
Regards,
Masato
prop-114-v001: Modification in the ASN eligibility criteria
Proposer: Aftab Siddiqui aftab.siddiqui@gmail.com mailto:aftab.siddiqui@gmail.com
Skeeve Stevensskeeve@eintellegonetworks.com mailto:skeeve@eintellegonetworks.com
- Problem statement
The current ASN assignment policy dictates two eligibility criteria and both should be fulfilled in order to get an ASN. The policy seems to imply that both requirements i.e. multi-homing and clearly defined single routing policy must be met simultaneously, this has created much confusion in interpreting the policy. As a result organizations have either provided incorrect information to get the ASN or barred themselves from applying.
- Objective of policy change
In order to make the policy guidelines simpler we are proposing to modify the text describing the eligibility criteria for ASN assignment by removing multi-homing requirement for the organization.
- Situation in other regions
ARIN: It is not mandatory but optional to be multi-homed in order get ASN
RIPE: Policy to remove multi-homing requirement is currently in discussion and the current phase ends 12 February 2015 Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
LACNIC: only inter-connect is mandatory not multi-homing
AFRINIC: It is mandatory to be multi-homed in order to get ASN.
- Proposed policy solution
An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months
- Advantages / Disadvantages
Advantages:
Removing the mandatory multi-homing requirement from the policy will make sure that organizations are not tempted to provide wrong information in order to fulfil the criteria of eligibility.Disadvantages:
No disadvantage.
- Impact on resource holders
No impact on existing resource holders.
- References
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Tue, Mar 3, 2015 at 12:43 PM, David Woodgate dwoodgate5@gmail.com wrote:
So I feel that:
- 4-byte ASs should simply be allocated upon request, with existing checks
removed;
OK. I agree with the reasoning that ASNs are not scarce. But see below.
- Reasonable annual fees (for example, $ per AS per year) could be charged
as a disincentive for frivolous requests.
Any fees would be too high for small operators, and trivially low for someone with a /15
- Or a cap could be imposed on the number of AS numbers allocated per
account;
- Or a combination of cap and charging; for example, up to xx ASs per
account are free, and then each additional AS will be charged at $yy per AS per year.
One ASN free for each /24 allocated? This means we will at worst "over-allocate" 0.4% of all ASN space
- Existing constraints should remain for 2-byte ASs
I do not understand this. Why are 2byte ASNs special? Is there new equipment being deployed that needs 2-byte ASNs? Is this a prestige thing?
(Serious question): Why would an operator prefer a 2byte over a 4byte? I do not type in my ASN very often.
Sanjeev,
See criterion #3 at https://blog.apnic.net/2014/09/02/2-byte-asn-run-out/ for a brief explanation of why 2-byte ASNs are still preferred for IXP peering.
Scott
On Mar 2, 2015, at 9:59 PM, Sanjeev Gupta sanjeev@dcs1.biz wrote:
On Tue, Mar 3, 2015 at 12:43 PM, David Woodgate dwoodgate5@gmail.com wrote:
So I feel that:
- 4-byte ASs should simply be allocated upon request, with existing checks removed;
OK. I agree with the reasoning that ASNs are not scarce. But see below.
- Reasonable annual fees (for example, $ per AS per year) could be charged as a disincentive for frivolous requests.
Any fees would be too high for small operators, and trivially low for someone with a /15
Or a cap could be imposed on the number of AS numbers allocated per account;
Or a combination of cap and charging; for example, up to xx ASs per account are free, and then each additional AS will be charged at $yy per AS per year.
One ASN free for each /24 allocated? This means we will at worst "over-allocate" 0.4% of all ASN space
- Existing constraints should remain for 2-byte ASs
I do not understand this. Why are 2byte ASNs special? Is there new equipment being deployed that needs 2-byte ASNs? Is this a prestige thing?
(Serious question): Why would an operator prefer a 2byte over a 4byte? I do not type in my ASN very often.
-- Sanjeev Gupta +65 98551208 http://sg.linkedin.com/in/ghane
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Tue, Mar 3, 2015 at 2:04 PM, Scott Leibrand scottleibrand@gmail.com wrote:
See criterion #3 at https://blog.apnic.net/2014/09/02/2-byte-asn-run-out/ for a brief explanation of why 2-byte ASNs are still preferred for IXP peering.
Scott, thank you. I was looking only at the other peer, and its equipment, supporting 4byte. As we are not using communities (small operator, here), I did not remember that use case.
Hi all,
I discussed with some folks from Japan who are here at APRICOT and would like to share a couple of observations:
* ASN assignments to those with portable assignments - Support from a number of people on ASN assignments to those with portable assignments is noted. - Howver, it is felt that it's better to set the criteria which is specific to ASN, not to make it dependent with portable assignment. - You don't know whether future changes in criteria for portable assighments will make sense as criteria for ASN assignments.
* Case of Pakistan It was helpful to hear about the case of Pakistan from Aftab, if I understood it correctly, wishes to be able to switch upstreams easily to ensure adequate service will be provided. It was felt that those needs should be tolerated and find ways to address it, questions were raised whether we should change the general criteria to address an indivisual case like this.
The feedback so far is let's think of ways to address those specific indivisual cases with issues, but if the current criteria works for most other people, we shouldn't adjust the default criteria for specific indivisual cases. This should be addressed seperately.
* Questions raised on its implication Looking at this from the situation in Japan, it may lead to a situation where some large ISPs may start applying more ASNs for the ease of its operation, for exapmple, applying for over 10 ASNs, or local CATV providers connected under group company's ASN may start applying even though they are able to operate today without global ASNs.
We may not need to worry about 4bite ASN pool but may have implications on routing, especially if path validation gets more deployed in the future.
* A suggestion An idea has been suggested to keep the multihoming criteria but not make it a must to be multihomed if an applicant can provide justification for the need for an ASN. There should still be a minimum criteria such as an applicant has BGP connection with its upstream, to need an ASN. To give rough guidance to APNIC and NIR hostmasters, give specific example of needs which has already being identified in the guidelines document.
e.g. It is expected that an applicant's environment of connectivity leads to the needs to constantly change upstreams with reasons explained
We have defined IPv6 distribution policy in a similar manner, withough changing the criteria which applies to most people. Specific cases are described in the guidelines.
What are the thoughts from the propers and others about this suggestion?
Izumi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 3/3/15 6:20 PM, Izumi Okutani wrote:
- Case of Pakistan It was helpful to hear about the case of
Pakistan from Aftab, if I understood it correctly, wishes to be able to switch upstreams easily to ensure adequate service will be provided. It was felt that those needs should be tolerated and find ways to address it, questions were raised whether we should change the general criteria to address an indivisual case like this.
I don't think this is specific to Pakistan. It's applicable across the board in the region. Carriers like to keep their customers captive everywhere, just the level of professionalism varies.
- -gaurab
Yes, this is the same in Cambodia, Laos, Myanmar, etc.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Mar 4, 2015 at 2:11 PM, Gaurab Raj Upadhaya gaurab@lahai.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 3/3/15 6:20 PM, Izumi Okutani wrote:
- Case of Pakistan It was helpful to hear about the case of
Pakistan from Aftab, if I understood it correctly, wishes to be able to switch upstreams easily to ensure adequate service will be provided. It was felt that those needs should be tolerated and find ways to address it, questions were raised whether we should change the general criteria to address an indivisual case like this.
I don't think this is specific to Pakistan. It's applicable across the board in the region. Carriers like to keep their customers captive everywhere, just the level of professionalism varies.
- -gaurab
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlT2lBgACgkQSo7fU26F3X2WXwCdF/dMBs+qYwEKVTeuUckJWF/5 TXIAn3rhAF1IKhNbHv++a+IK/RMr8nLP =YrfM -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
I see, understood Gaurab and Skeeve it's not just a case of Pakistan.
Would it accomodate the situation if the criteria is revised as below?
a. Mutlihomed/plan to be multihomed in the near future OR b. A single homed but is/plans to be connected by BGP with upstream if wit justification of why an ASN is needed for such network
Put it in the guidelines that a case such asit is expected that an applicant's environment of connectivity leads to the needs to constantly change upstreams can be a reason to justify b.
I haven't talked to operators from Japan about this so would also welcome their feedback (or anyone else offcourse!) if this is likely to creat issues.
Izumi
On 2015/03/04 14:15, Skeeve Stevens wrote:
Yes, this is the same in Cambodia, Laos, Myanmar, etc.
...Skeeve
*Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service skeeve@v4now.com ; www.v4now.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
IP Address Brokering - Introducing sellers and buyers
On Wed, Mar 4, 2015 at 2:11 PM, Gaurab Raj Upadhaya gaurab@lahai.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 3/3/15 6:20 PM, Izumi Okutani wrote:
- Case of Pakistan It was helpful to hear about the case of
Pakistan from Aftab, if I understood it correctly, wishes to be able to switch upstreams easily to ensure adequate service will be provided. It was felt that those needs should be tolerated and find ways to address it, questions were raised whether we should change the general criteria to address an indivisual case like this.
I don't think this is specific to Pakistan. It's applicable across the board in the region. Carriers like to keep their customers captive everywhere, just the level of professionalism varies.
- -gaurab
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iEYEARECAAYFAlT2lBgACgkQSo7fU26F3X2WXwCdF/dMBs+qYwEKVTeuUckJWF/5 TXIAn3rhAF1IKhNbHv++a+IK/RMr8nLP =YrfM -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Activity Summary
- 2946 days inactive
- 2946 days old
- sig-policy@lists.apnic.net
- 20 participants
- 78 comments