Re: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement
Hello, On 07/11/2014 11:21 AM, Marco Schmidt wrote:
The draft document for the proposal described in 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been published. The impact analysis that was conducted for this proposal has also been published.
I know I'm late in the game, but I thought I'd contribute this view rather than stay silent: Remove multi homing requirement for 32bit ASNs only, keep the requirement for 16bit ASNs. I foresee new weird legacy setups run by non-ISPs that still require a unique ASN well into the future. The example I would usually use is factory floor environments, but that is probably not an applicable example here. I hope someone else's imagination can supply a valid example. Cheers, -- Aleksi Suhonen You say "potato", I say "closest-exit."
Dear all, Based on the feedback from the working group we have developed a new iteration of the proposal. Concerns addressed: - remove private AS Number reference (Fredy Kuenzler, 1 May 2014; Alex le Heux, offlist; Erik Bais, offlist) - differentiate between 16 and 32 bit ASN (Nick Hilliard, 1 May 2014; Aleksi Suhonen, 14 August 2014; RIPE NCC Impact analysis section B "Autonomous System Number (ASN) Consumption") - Specify timeline when multihoming is required (Janos Zsako, 11 Jul 2014 What has not been addressed is the creation of an exhaustive list of acceptable reasons to request an ASN. The authors do not know how to update (without full PDP process) the list when new technologies or methodologies arise. Rather, the authors believe that RIPE NCC is responsible for maintaining an accurate registry than evaluate network designs. In a years time the RIPE NCC could publish an aggregated report on the recorded needs, possibly to inspire the community to reconsider this policy. ----------------- replaces section 2.0 from RIPE-525 ----------------- 2.0 Assignment Criteria A new AS Number should only be assigned when the End User expresses a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. When requesting a 16 bit AS Number, the network must be multihomed using the assigned AS Number within 6 months. A 32 bit AS Number is exempt from the multihoming requirement. When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. ------------------------------------------------------------------------ Kind regards, Job & Ytti
On 16/08/2014 12:31, Job Snijders wrote:
A new AS Number should only be assigned when the End User expresses a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need.
This is an excellent idea. I have a legitimate operational need for a large number of autonomous system numbers - slightly less than 2^32. The rest of the internet will be left with a couple of thousand which should do for the rest of time, assuming that they're handled sparingly. Anyways, people can use the private assignment range if they're stuck. The RIPE NCC can record my need and keep it confidential. So count this as definite support for the proposal as it stands. Nick
On Sat, Aug 16, 2014 at 01:09:40PM +0100, Nick Hilliard wrote:
On 16/08/2014 12:31, Job Snijders wrote:
A new AS Number should only be assigned when the End User expresses a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need.
This is an excellent idea. I have a legitimate operational need for a large number of autonomous system numbers - slightly less than 2^32. The rest of the internet will be left with a couple of thousand which should do for the rest of time, assuming that they're handled sparingly. Anyways, people can use the private assignment range if they're stuck.
Already today you can request slightly less than 2^32 ASNs. For each request indicate that the requested ASN will peer with the two ASNs requested previously.
So count this as definite support for the proposal as it stands.
Thank you for your support. Kind regards, Job
On 16 August 2014 15:22, Job Snijders <job@instituut.net> wrote:
Already today you can request slightly less than 2^32 ASNs. For each request indicate that the requested ASN will peer with the two ASNs requested previously.
ACK. And if there seem to be worrying request rate, situation is unchanged, we need to address that, with today's policy and with tomorrow's policy. I personally would want to see YRC implemented, 1EUR/year/resource, 4294967296 EUR annual revenue will make it possible to finance sufficient long AS number for Nick's use cases. -- ++ytti
Hi, On Sat, Aug 16, 2014 at 04:33:57PM +0300, Saku Ytti wrote:
I personally would want to see YRC implemented, 1EUR/year/resource, 4294967296 EUR annual revenue will make it possible to finance sufficient long AS number for Nick's use cases.
Unfortunately, APWG has no formal say in this, as everything related to money is for the members to decide, and it seems sufficient LIRs wanted "no extra costs for AS numbers!" to lobby for the removal from the charging scheme... (we had "50 EUR per AS/year" in it) One would need to personally propose this to the board so they can include it in the new charging scheme drafts, *and* get enough members to actually vote for it... Gert Doering -- no particular hats -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Sat, Aug 16, 2014 at 03:50:56PM +0200, Gert Doering wrote:
On Sat, Aug 16, 2014 at 04:33:57PM +0300, Saku Ytti wrote:
I personally would want to see YRC implemented, 1EUR/year/resource, 4294967296 EUR annual revenue will make it possible to finance sufficient long AS number for Nick's use cases.
Unfortunately, APWG has no formal say in this, as everything related to money is for the members to decide, and it seems sufficient LIRs wanted "no extra costs for AS numbers!" to lobby for the removal from the charging scheme... (we had "50 EUR per AS/year" in it)
One would need to personally propose this to the board so they can include it in the new charging scheme drafts, *and* get enough members to actually vote for it...
As author I wholeheartedly agree with the two main concerns Nick raises, we described this concern in the Rationale section B. Going forward I see two possible paths, and would appreciate feedback on either. 1) We add a clause to the policy that the policy only takes effect if either in 2014 or 2015, a yearly recurring cost is associated with AS Number assigments. Until then RIPE-525 remains in effect as is. 2) We limited the number of AS Number assignments per LIR to one thousand. This currently values an AS Number assignment at roughly 2 euros, which in my opinion would be a fine number. This approach would have both an abuse-dampening and a garbage collection effect. Thoughts? Kind regards, Job
Hi Job, Policy can't set a price or affect the cost to a resource, as that is decided by the membership in the AGM. I would rather have the NCC monitor the situation and report on it during the NCC services update on the RIPE meetings as they are also doing on the PI IPv6 without multihoming. If the situation would show abusive behaviour from people, the need is there to associate a cost per AS object and you would get it much easier through the AGM ... I would not recommend writing a policy that would only be implemented after a cost decision. And by writing that the Currently policy must stay as is, also doesn't leave an option to make other adjustments.. May I suggest the policy change that was discussed to be able to transfer an ASn. Regards, Erik Bais Verstuurd vanaf mijn iPad
Op 16 aug. 2014 om 16:34 heeft Job Snijders <job@instituut.net> het volgende geschreven:
On Sat, Aug 16, 2014 at 03:50:56PM +0200, Gert Doering wrote:
On Sat, Aug 16, 2014 at 04:33:57PM +0300, Saku Ytti wrote: I personally would want to see YRC implemented, 1EUR/year/resource, 4294967296 EUR annual revenue will make it possible to finance sufficient long AS number for Nick's use cases.
Unfortunately, APWG has no formal say in this, as everything related to money is for the members to decide, and it seems sufficient LIRs wanted "no extra costs for AS numbers!" to lobby for the removal from the charging scheme... (we had "50 EUR per AS/year" in it)
One would need to personally propose this to the board so they can include it in the new charging scheme drafts, *and* get enough members to actually vote for it...
As author I wholeheartedly agree with the two main concerns Nick raises, we described this concern in the Rationale section B.
Going forward I see two possible paths, and would appreciate feedback on either.
1) We add a clause to the policy that the policy only takes effect if either in 2014 or 2015, a yearly recurring cost is associated with AS Number assigments. Until then RIPE-525 remains in effect as is.
2) We limited the number of AS Number assignments per LIR to one thousand. This currently values an AS Number assignment at roughly 2 euros, which in my opinion would be a fine number. This approach would have both an abuse-dampening and a garbage collection effect.
Thoughts?
Kind regards,
Job
On Sat, Aug 16, 2014 at 05:36:46PM +0200, Erik Bais wrote:
Policy can't set a price or affect the cost to a resource, as that is decided by the membership in the AGM.
Yes I know, hence my presenting of these two paths forward.
I would rather have the NCC monitor the situation and report on it during the NCC services update on the RIPE meetings as they are also doing on the PI IPv6 without multihoming. If the situation would show abusive behaviour from people, the need is there to associate a cost per AS object and you would get it much easier through the AGM ...
I would not recommend writing a policy that would only be implemented after a cost decision. And by writing that the Currently policy must stay as is, also doesn't leave an option to make other adjustments..
Noted.
May I suggest the policy change that was discussed to be able to transfer an ASn.
Do you have an URL? What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns. Kind regards, Job
What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns.
So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR ... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ... Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ... And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ? You may want to ask Andrea as he might know what the current number is ( max) hold within an LIR ( not including Legacy assigned AS numbers) ... Personally I don't think it will be a lot that have more 5 AS'n in their LIR ( especially for their own Infra) .. There might be some that have a list of AS's requested for end-users. I know I have ... But if a customer doesn't require an AS number, why would one request an AS number if the customer doesn't understand what BGP is or if they don't intend to run BGP ? Which might actually be the better question in this discussion to ask instead of asking if you are going to multihome ... Are you going to run BGP ? And if you are, have you considered a private AS to use instead of a unique AS number .. Which basically covers everything that the NCC should know ... Or am I missing something ? Regards, Erik Bais Verstuurd vanaf mijn iPad
Op 16 aug. 2014 om 17:46 heeft Job Snijders <job@instituut.net> het volgende geschreven:
On Sat, Aug 16, 2014 at 05:36:46PM +0200, Erik Bais wrote:
Policy can't set a price or affect the cost to a resource, as that is decided by the membership in the AGM.
Yes I know, hence my presenting of these two paths forward.
I would rather have the NCC monitor the situation and report on it during the NCC services update on the RIPE meetings as they are also doing on the PI IPv6 without multihoming. If the situation would show abusive behaviour from people, the need is there to associate a cost per AS object and you would get it much easier through the AGM ...
I would not recommend writing a policy that would only be implemented after a cost decision. And by writing that the Currently policy must stay as is, also doesn't leave an option to make other adjustments..
Noted.
May I suggest the policy change that was discussed to be able to transfer an ASn.
Do you have an URL?
What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns.
Kind regards,
Job
On Sat, Aug 16, 2014 at 06:07:24PM +0200, Erik Bais wrote:
What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns.
So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ?
Yes, looks like correct math to me. :-)
Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR
Our fear was one LIR consuming all of the remaining ASNs (4.200.000.000 or so?), this is what I try to address.
... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ...
That does not bother me.
Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ...
OK!
And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ?
Can you please rephrase the above paragraph? I don't follow.
You may want to ask Andrea as he might know what the current number is ( max) hold within an LIR ( not including Legacy assigned AS numbers) ... Personally I don't think it will be a lot that have more 5 AS'n in their LIR ( especially for their own Infra) .. There might be some that have a list of AS's requested for end-users. I know I have ... But if a customer doesn't require an AS number, why would one request an AS number if the customer doesn't understand what BGP is or if they don't intend to run BGP ?
That is entirely up to these LIRs. The purpose of the policy proposal is to make it easier to obtain an ASN, yet at the same time prevent abusing the liberty the policy could provide. Obtaining AS numbers should be simple for both the very large LIRs and the small LIRs. Setting limit to 5 or even 100 would directly lead to issues for some companies.
Which might actually be the better question in this discussion to ask instead of asking if you are going to multihome ... Are you going to run BGP ? And if you are, have you considered a private AS to use instead of a unique AS number .. Which basically covers everything that the NCC should know ... Or am I missing something ?
Private ASNs are not of any concern to the RIPE NCC. Would be the same as asking for a /29 or /48 IPv6 and being asked "Have you considered using ULA Space?". The answer always is "No, I need a globally unique integer, otherwise I would not go to RIPE NCC for resources" Currently there are 10.692 LIRs, this means a policy proposal (following path 2), could lay claim to 10.692.000 ASNs, iff all LIRS would request the maximum. That unlikely scenario would lead to ~ 0.002% of available ASNs being consumed. I am certain only a very small subset of LIRs will need more than a handful AS number assignments. And in the awkward scenario where some organisation launches a 2000 new LIRs, this would decrease LIR membership fee for everybody significantly, yet still pose no real risk to all ASNs being consumed. Kind regards, Job
And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ?
Can you please rephrase the above paragraph? I don't follow.
Lets try that again, freaking auto-correct and thick fingers.. So, what if you would request ASn's for end-users as a sponsoring LIR, would that count ? Or would only the own infra AS numbers count within an LIR ..
Private ASNs are not of any concern to the RIPE NCC. Would be the same as asking for a /29 or /48 IPv6 and being asked "Have you considered using ULA Space?". The answer always is "No, I need a globally unique integer, otherwise I would not go to RIPE NCC for resources"
True, but that was also the question when requesting IPv4. (Rfc1918 space) There might be more to it than an open door. Some people are actually requesting resources without looking at the private use options.. Erik Verstuurd vanaf mijn iPad
Op 16 aug. 2014 om 18:39 heeft Job Snijders <job@instituut.net> het volgende geschreven:
On Sat, Aug 16, 2014 at 06:07:24PM +0200, Erik Bais wrote:
What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns.
So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ?
Yes, looks like correct math to me. :-)
Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR
Our fear was one LIR consuming all of the remaining ASNs (4.200.000.000 or so?), this is what I try to address.
... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ...
That does not bother me.
Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ...
OK!
And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ?
Can you please rephrase the above paragraph? I don't follow.
You may want to ask Andrea as he might know what the current number is ( max) hold within an LIR ( not including Legacy assigned AS numbers) ... Personally I don't think it will be a lot that have more 5 AS'n in their LIR ( especially for their own Infra) .. There might be some that have a list of AS's requested for end-users. I know I have ... But if a customer doesn't require an AS number, why would one request an AS number if the customer doesn't understand what BGP is or if they don't intend to run BGP ?
That is entirely up to these LIRs. The purpose of the policy proposal is to make it easier to obtain an ASN, yet at the same time prevent abusing the liberty the policy could provide. Obtaining AS numbers should be simple for both the very large LIRs and the small LIRs. Setting limit to 5 or even 100 would directly lead to issues for some companies.
Which might actually be the better question in this discussion to ask instead of asking if you are going to multihome ... Are you going to run BGP ? And if you are, have you considered a private AS to use instead of a unique AS number .. Which basically covers everything that the NCC should know ... Or am I missing something ?
Private ASNs are not of any concern to the RIPE NCC. Would be the same as asking for a /29 or /48 IPv6 and being asked "Have you considered using ULA Space?". The answer always is "No, I need a globally unique integer, otherwise I would not go to RIPE NCC for resources"
Currently there are 10.692 LIRs, this means a policy proposal (following path 2), could lay claim to 10.692.000 ASNs, iff all LIRS would request the maximum. That unlikely scenario would lead to ~ 0.002% of available ASNs being consumed.
I am certain only a very small subset of LIRs will need more than a handful AS number assignments. And in the awkward scenario where some organisation launches a 2000 new LIRs, this would decrease LIR membership fee for everybody significantly, yet still pose no real risk to all ASNs being consumed.
Kind regards,
Job
On Sat, Aug 16, 2014 at 07:49:11PM +0200, Erik Bais wrote:
So, what if you would request ASn's for end-users as a sponsoring LIR, would that count ? Or would only the own infra AS numbers count within an LIR ..
To me they are all just integers, any difference is academic at best. Kind regards, Job
On Sat, 16 Aug 2014, Erik Bais wrote:
What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns.
So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR ... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ...
Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ...
And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ?
Yes, I think that would be two completly different things. We have a few dozen ASn's tied to a single LIR, most of wich are used by different end users. But as we regularly apply for new ASn's on behalf of end users I am a bit confused here. The suggestion is to take away the multi homing requirement, right? But today, you always get a lot of questions from the NCC if you apply for a second ASn for the same end user. It is not like you will easily get millions of ASn's today just because you can come up with new combinations of 'two peerings'. I might be missing something though. And yes, I would have liked the annual ASn fee to stay. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
Dear Erik and colleagues, We would like to provide you with some numbers. In the RIPE NCC service region, there are currently 10,874 ASNs assigned to LIRs and 14,181 ASNs assigned to End Users with approved documents. There are 26 organisations (including six with legacy ASNs) with more than ten ASNs registered. The maximum number of ASNs assigned to one organization is 100 (not including legacy ASNs). We hope that this is helps your discussion. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On 16/08/14 18:07, Erik Bais wrote:
What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns. So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR ... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ...
Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ...
And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ?
You may want to ask Andrea as he might know what the current number is ( max) hold within an LIR ( not including Legacy assigned AS numbers) ... Personally I don't think it will be a lot that have more 5 AS'n in their LIR ( especially for their own Infra) .. There might be some that have a list of AS's requested for end-users. I know I have ... But if a customer doesn't require an AS number, why would one request an AS number if the customer doesn't understand what BGP is or if they don't intend to run BGP ?
Which might actually be the better question in this discussion to ask instead of asking if you are going to multihome ... Are you going to run BGP ? And if you are, have you considered a private AS to use instead of a unique AS number .. Which basically covers everything that the NCC should know ... Or am I missing something ?
Regards, Erik Bais
Verstuurd vanaf mijn iPad
Op 16 aug. 2014 om 17:46 heeft Job Snijders <job@instituut.net> het volgende geschreven:
On Sat, Aug 16, 2014 at 05:36:46PM +0200, Erik Bais wrote:
Policy can't set a price or affect the cost to a resource, as that is decided by the membership in the AGM. Yes I know, hence my presenting of these two paths forward.
I would rather have the NCC monitor the situation and report on it during the NCC services update on the RIPE meetings as they are also doing on the PI IPv6 without multihoming. If the situation would show abusive behaviour from people, the need is there to associate a cost per AS object and you would get it much easier through the AGM ...
I would not recommend writing a policy that would only be implemented after a cost decision. And by writing that the Currently policy must stay as is, also doesn't leave an option to make other adjustments.. Noted.
May I suggest the policy change that was discussed to be able to transfer an ASn. Do you have an URL?
What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns.
Kind regards,
Job
On Sat, Aug 16, 2014 at 4:34 PM, Job Snijders <job@instituut.net> wrote:
2) We limited the number of AS Number assignments per LIR to one thousand. This currently values an AS Number assignment at roughly 2 euros, which in my opinion would be a fine number. This approach would have both an abuse-dampening and a garbage collection effect.
I do agree with the aim of the proposal and while I don't see the same potential for abuse as Nick does, mainly because I see no real use or value in having a myriad of ASNs just lying around. Reinstating the 50€/year scheme may make sense, here. As to the option above, at first glance 1000 seems like a lot, but without supporting data, it's hard to tell. Requiring, and verifying, documentation after X ASN may be an option, but this feels like a bandaid where the simple fee used to be. Richard PS: For Gert's benefit: I support this proposal in its current form already, even though there's still room for improvement.
On 16/08/2014 15:34, Job Snijders wrote:
Going forward I see two possible paths, and would appreciate feedback on either.
1) We add a clause to the policy that the policy only takes effect if either in 2014 or 2015, a yearly recurring cost is associated with AS Number assigments. Until then RIPE-525 remains in effect as is.
It would be better to bring this up as an agenda item at the next NCC GM and get this problem fixed rather than putting conditionals into the policy.
2) We limited the number of AS Number assignments per LIR to one thousand.
Please let's not create policy by application of comfortingly round numbers. Nick
On 16 August 2014 20:45, Nick Hilliard <nick@inex.ie> wrote:
It would be better to bring this up as an agenda item at the next NCC GM and get this problem fixed rather than putting conditionals into the policy.
2) We limited the number of AS Number assignments per LIR to one thousand.
Please let's not create policy by application of comfortingly round numbers.
I agree, the policy is (and should) be simple and without contrived complexity to fix real issue in wrong place. The abuse potential is in current policy as well. so it should not factor in here either, they can be tackled separately, but I definitely support tackling the problem. It is such a simple, elegant and obvious way to manage finite resources, put non-zero cost to them. It fixes other complex problems as well, not just arbitrary policy abuse. -- ++ytti
On 16/08/14 18:45, Nick Hilliard wrote:
On 16/08/2014 15:34, Job Snijders wrote:
Going forward I see two possible paths, and would appreciate feedback on either.
1) We add a clause to the policy that the policy only takes effect if either in 2014 or 2015, a yearly recurring cost is associated with AS Number assigments. Until then RIPE-525 remains in effect as is. It would be better to bring this up as an agenda item at the next NCC GM and get this problem fixed rather than putting conditionals into the policy.
And the board has noted your request... we'll discuss at the next board meeting which is in early September. All the best Nigel
Hi, On Sat, Aug 16, 2014 at 01:09:40PM +0100, Nick Hilliard wrote:
So count this as definite support for the proposal as it stands.
Uh. I find it slightly hard to judge whether this was sarcastic or whether you are actually indeed supporting the proposal...? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 16/08/2014 13:58, Gert Doering wrote:
Uh. I find it slightly hard to judge whether this was sarcastic or whether you are actually indeed supporting the proposal...?
you can probably tell I was joking. I don't support proposals when there are no basic mechanisms in place to stop people from abusing them. Previously, this could have been enforced by the €50 fee per annum for each ASN, but this fee disappeared in the 2013 RIPE NCC charging scheme on recommendation from the RIPE NCC Charging Scheme Task Force:
http://www.ripe.net/lir-services/ncc/gm/april-2012/supporting-documents/repo... http://www.ripe.net/lir-services/ncc/gm/april-2012/presentations/report-of-t...
The task force reported this: "The task force thought that charging for ASNs was unnecessary. Members who have ASNs also have address space so they will still be charged." The Task Force did not take into account that charging for resources also acts as a simple but effective abuse-dampening mechanism, which was one of the original reasons that charging for PI resources went into the contractual requirements policy (the other main reason was that charging for resources acts as a simple garbage collection mechanism, which we have also lost). I had planned to object to this at the 2012 RIPE NCC GM but unfortunately wasn't able to attend the meeting. If this policy is passed as-is, then anyone will be able to abuse the policy to request an arbitrary number of ASNs for any reason, and the RIPE NCC will not be able to refuse the request. This is a particular problem given that we have a shortage of ASN16s and a feature disparity between ASN16s and ASN32s. I have no major problem problem handing out ASNs on request but if we do, there needs to be a damper mechanism in place to stop abuse. To do this, either APWG should put in place a policy for the RIPE NCC to evaluate ASN requests and assign according to need, or else it should charge for ASN assignments. I strongly favour the latter, as it is simpler and less ambiguous. It also restores the garbage collection mechanism which we previously had and have now lost. Nick
Hi Job, As stated to you offlist, I support the idea of the proposal, but I can't disagree with the NCC review of how the current proposal is written. I think a lot of the discussion can be removed by changing the word MUST into a SHOULD in section 2.0 of ripe-525 Personally I don't think the NCC should go further into asking if a requestor has considered the use of a private AS, but shouldn't enforce or question the motives of someone not to want to use a private AS. I can imagine that there are operational use cases for requesting a unique ASn without someone going full multi-homing at implementation. I rather have someone register for a AS instead of picking some random number which might lead to other issues globally or lie tot the NCC in order to obtain one. I trust the NCC to monitor abuse of the intended policy on actual impact, which will allow more than sufficient time to change the charging scheme if needed in the future to bite guys like Nick in the ..... ;-) Regards, Erik Bais Verstuurd vanaf mijn iPad
Op 16 aug. 2014 om 13:31 heeft Job Snijders <job@instituut.net> het volgende geschreven:
Dear all,
Based on the feedback from the working group we have developed a new iteration of the proposal.
Concerns addressed:
- remove private AS Number reference (Fredy Kuenzler, 1 May 2014; Alex le Heux, offlist; Erik Bais, offlist) - differentiate between 16 and 32 bit ASN (Nick Hilliard, 1 May 2014; Aleksi Suhonen, 14 August 2014; RIPE NCC Impact analysis section B "Autonomous System Number (ASN) Consumption") - Specify timeline when multihoming is required (Janos Zsako, 11 Jul 2014
What has not been addressed is the creation of an exhaustive list of acceptable reasons to request an ASN. The authors do not know how to update (without full PDP process) the list when new technologies or methodologies arise. Rather, the authors believe that RIPE NCC is responsible for maintaining an accurate registry than evaluate network designs. In a years time the RIPE NCC could publish an aggregated report on the recorded needs, possibly to inspire the community to reconsider this policy.
----------------- replaces section 2.0 from RIPE-525 ----------------- 2.0 Assignment Criteria
A new AS Number should only be assigned when the End User expresses a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need.
When requesting a 16 bit AS Number, the network must be multihomed using the assigned AS Number within 6 months. A 32 bit AS Number is exempt from the multihoming requirement.
When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. ------------------------------------------------------------------------
Kind regards,
Job & Ytti
With "the cloud" allowing for effective single homing these days, do we really need to codify any sort of multi-homing requirement? I also don't see the utility of a list of reasons that someone can be assigned an ASN. Isn't "I'm connecting to a network and speaking bgp" good enough. Best, -M< On Aug 16, 2014, at 7:31 AM, Job Snijders <job@instituut.net> wrote:
Dear all,
Based on the feedback from the working group we have developed a new iteration of the proposal.
Concerns addressed:
- remove private AS Number reference (Fredy Kuenzler, 1 May 2014; Alex le Heux, offlist; Erik Bais, offlist) - differentiate between 16 and 32 bit ASN (Nick Hilliard, 1 May 2014; Aleksi Suhonen, 14 August 2014; RIPE NCC Impact analysis section B "Autonomous System Number (ASN) Consumption") - Specify timeline when multihoming is required (Janos Zsako, 11 Jul 2014
What has not been addressed is the creation of an exhaustive list of acceptable reasons to request an ASN. The authors do not know how to update (without full PDP process) the list when new technologies or methodologies arise. Rather, the authors believe that RIPE NCC is responsible for maintaining an accurate registry than evaluate network designs. In a years time the RIPE NCC could publish an aggregated report on the recorded needs, possibly to inspire the community to reconsider this policy.
----------------- replaces section 2.0 from RIPE-525 ----------------- 2.0 Assignment Criteria
A new AS Number should only be assigned when the End User expresses a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need.
When requesting a 16 bit AS Number, the network must be multihomed using the assigned AS Number within 6 months. A 32 bit AS Number is exempt from the multihoming requirement.
When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. ------------------------------------------------------------------------
Kind regards,
Job & Ytti
On 17 August 2014 00:08, Hannigan, Martin <marty@akamai.com> wrote:
With "the cloud" allowing for effective single homing these days, do we really need to codify any sort of multi-homing requirement? I also don't see the utility of a list of reasons that someone can be assigned an ASN. Isn't "I'm connecting to a network and speaking bgp" good enough.
16b are scarce and special, and one application where you really want to have 16b ASN is when you have >1 upstream and >0 downstream, then you really want to support TE via communities, and for this you are in competitive disadvantage without 16b ASN. Otherwise agreed. -- ++ytti
On Sun, Aug 17, 2014 at 12:25:18AM +0300, Saku Ytti wrote:
With "the cloud" allowing for effective single homing these days, do we really need to codify any sort of multi-homing requirement? I also don't see the utility of a list of reasons that someone can be assigned an ASN. Isn't "I'm connecting to a network and speaking bgp" good enough.
16b are scarce and special, and one application where you really want to have 16b ASN is when you have >1 upstream and >0 downstream, then you really want to support TE via communities, and for this you are in competitive disadvantage without 16b ASN.
The need for TE communities may already exist with multihoming to a single upstream AS. E.g. TE comms to modify localpref to make a link strict-backup in multihoming-to-single-upstream situations. Think 702:[789] Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
participants (12)
-
Aleksi Suhonen -
Daniel Roesen -
Daniel Stolpe -
Erik Bais -
Gert Doering -
Hannigan, Martin -
Job Snijders -
Marco Schmidt -
Nick Hilliard -
Nigel Titley -
Richard Hartmann -
Saku Ytti