2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)
Dear colleagues, The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 We encourage you to review this policy proposal and send your comments to <address-policy-wg@ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC
Support. +1. I've read the "Arguments opposing the proposal", and i don't believe fragmentation will significantly increase as a result of this policy. Anyway some people already fragment more than they should... :-) Regards, Carlos On Mon, 9 Mar 2015, Marco Schmidt wrote:
Dear colleagues,
The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015.
You can find the full proposal at:
https://www.ripe.net/ripe/policies/proposals/2014-03
We encourage you to review this policy proposal and send your comments to <address-policy-wg@ripe.net>.
Regards,
Marco Schmidt Policy Development Officer RIPE NCC
Support +1 for this Den 2015-04-28 08:33 skrev Carlos Friacas <cfriacas@fccn.pt>:
Support. +1.
I've read the "Arguments opposing the proposal", and i don't believe fragmentation will significantly increase as a result of this policy.
Anyway some people already fragment more than they should... :-)
Regards, Carlos
On Mon, 9 Mar 2015, Marco Schmidt wrote:
Dear colleagues,
The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015.
You can find the full proposal at:
https://www.ripe.net/ripe/policies/proposals/2014-03
We encourage you to review this policy proposal and send your comments to <address-policy-wg@ripe.net>.
Regards,
Marco Schmidt Policy Development Officer RIPE NCC
+1 Strongly support. -- -------------------------------------------- I Hamed Shafaghi I I Managing Director I I Skydsl® Telecom I hamed@skydsl.ir I www.skydsl.ir I
Dear AP WG, On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote:
The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015.
So - we extended this to wait for the AGM decision on "charging for AS numbers". The AGM decided, and the clear majority decide to not introduce annual charges for AS numbers - my life would be easier otherwise, but this is what was decided, so respect it and see how we can achive our goals here :-) Feedback for this proposal so far was, if I simplify a bit - we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?) - we might want a garbage collection / reclamation mechanism - the current policy text is too complicate, arbitrary numbers are bad but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check". So, what should we (or, more precise, the proposers) do to get there? Nick, I'm actually looking at you since you threw the most sand into the gears here... some specific suggestions how you'd tackle this would be welcome. (Technically, I see no other way than to change text and do another round of IA/review phase with the feedback we've received until now - if, based on the new background from AGM, everybody who has objected so far is now accepting this at it stands to go forward - please say so!) 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
Gert, On 15/05/2015 13:34, Gert Doering wrote:
Feedback for this proposal so far was, if I simplify a bit
- we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
- we might want a garbage collection / reclamation mechanism
- the current policy text is too complicate, arbitrary numbers are bad
but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check".
I'm going to suggest taking a step back and looking at the problem from a distance so that we can get a better view of how to approach it. We have two generic categories of assignment policy in the RIPE region: needs-based and entitlement-based. - needs-based policies operate on the basis of a stated requirement of some form, where this requirement undergoes some form of evaluation. - entitlement-based assignment operates on the principal that if you request a resource of some form within particular parameters, you will get the resource with no requirement to justify it. If you stray outside the specified parameters, then one of two things happens: either a needs-based policy will apply or the request will be denied by policy. Needs-based policies have historically worked well for constrained resources (ipv4 and ASNs). On the other hand where a resource is abundant, these policies can be cumbersome or unnecessary. In terms of resource run-out, ASN16s will be gone sooner or later, pretty much no matter what policy is put in place. Conversely, the supply of ASN32s is not constrained; nor is it likely to be in future. We have an ASN transfer policy, which is good. The questions relevant to creating a new policy for handling ASN assignments are: - would it be useful to implement an asn16 runout policy? - outside that, is there a need to have separate policies for ASN16s and ASN32s? - for all these cases, would it be best to use needs-based policies, entitlement-based policies or something else? - if it's appropriate to put in a needs-based policy, can we define what "need" is? e.g. would it be useful to collate a set of use-cases that the RIPE NCC could use to evaluate requests? - if an entitlement-based policy is implemented, is it an unlimited entitlement policy, or does it transform to a needs-based or a deny based policy outside specific parameters? No doubt I have left many important things out. If the answers to these questions suggest that we need a new policy, we need also need to evaluate whether the new policy which results is better than the existing one, for some meaning of the word "better". Nick
In reply to Nick Hilliard's post this evening, I wanted to share some data. In AS8075 (Microsoft's primary network), we have a lot of incompatibility with 4-byte AS numbers. We have equipment from some vendors who don't support it at all (like Arista), or support it without being able to remove-private on the extended range (important for locally-unique AS number usage) We've filed feature requests with all parties, and our spend with these vendors should justify fast tracking feature requests. And yet ... nothing here in May 2015. RFC4893 was published EIGHT years ago, and vendors are just not all that far along. If the RIRs don't do anything to preserve 2-byte AS numbers, then things are going to start really breaking. That should get vendors to wake up. But that's not a good scenario. On the other hand, there's no stopping 2-byte exhaustion: the velocity of 2-byte number registration is too fast - we'll be out soon enough no matter what we do. David R Huberman Principal, Global IP Addressing Microsoft Corporation
-----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Nick Hilliard Sent: Friday, May 15, 2015 4:40 PM To: Gert Doering; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)
Gert,
On 15/05/2015 13:34, Gert Doering wrote:
Feedback for this proposal so far was, if I simplify a bit
- we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
- we might want a garbage collection / reclamation mechanism
- the current policy text is too complicate, arbitrary numbers are bad
but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check".
I'm going to suggest taking a step back and looking at the problem from a distance so that we can get a better view of how to approach it.
We have two generic categories of assignment policy in the RIPE region: needs-based and entitlement-based.
- needs-based policies operate on the basis of a stated requirement of some form, where this requirement undergoes some form of evaluation.
- entitlement-based assignment operates on the principal that if you request a resource of some form within particular parameters, you will get the resource with no requirement to justify it. If you stray outside the specified parameters, then one of two things happens: either a needs-based policy will apply or the request will be denied by policy.
Needs-based policies have historically worked well for constrained resources (ipv4 and ASNs). On the other hand where a resource is abundant, these policies can be cumbersome or unnecessary.
In terms of resource run-out, ASN16s will be gone sooner or later, pretty much no matter what policy is put in place. Conversely, the supply of ASN32s is not constrained; nor is it likely to be in future.
We have an ASN transfer policy, which is good.
The questions relevant to creating a new policy for handling ASN assignments are:
- would it be useful to implement an asn16 runout policy?
- outside that, is there a need to have separate policies for ASN16s and ASN32s?
- for all these cases, would it be best to use needs-based policies, entitlement-based policies or something else?
- if it's appropriate to put in a needs-based policy, can we define what "need" is? e.g. would it be useful to collate a set of use-cases that the RIPE NCC could use to evaluate requests?
- if an entitlement-based policy is implemented, is it an unlimited entitlement policy, or does it transform to a needs-based or a deny based policy outside specific parameters?
No doubt I have left many important things out.
If the answers to these questions suggest that we need a new policy, we need also need to evaluate whether the new policy which results is better than the existing one, for some meaning of the word "better".
Nick
On 16/05/2015 03:33, David Huberman wrote:
If the RIRs don't do anything to preserve 2-byte AS numbers, then things are going to start really breaking.
s/RIRs don't do anything to preserve/vendors don't to anything to support/ ASN16 runout is inevitable and is now within sight: IANA's stock is gone. The RIRs can twiddle policy this way or that, but they can't stop runout and will find it difficult even to slow it down. If the vendors are pretending otherwise - either to themselves or their customers - then they are deluded. If RIR run-out hits before they have implemented asn32 support and shaken out all the bugs, then they will find that their kit is obsolete for new customers and this will have commercial implications for them. Nick
Hi Gert, There are a couple things that I keep reading and hearing in the discussion here.. Run-out of 16 bit as's and garbage collection.. May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence ) Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update. The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at. Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour. Regards, Erik Bais Verstuurd vanaf mijn iPad
Op 15 mei 2015 om 14:34 heeft Gert Doering <gert@space.net> het volgende geschreven:
Dear AP WG,
On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015.
So - we extended this to wait for the AGM decision on "charging for AS numbers". The AGM decided, and the clear majority decide to not introduce annual charges for AS numbers - my life would be easier otherwise, but this is what was decided, so respect it and see how we can achive our goals here :-)
Feedback for this proposal so far was, if I simplify a bit
- we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
- we might want a garbage collection / reclamation mechanism
- the current policy text is too complicate, arbitrary numbers are bad
but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check".
So, what should we (or, more precise, the proposers) do to get there?
Nick, I'm actually looking at you since you threw the most sand into the gears here... some specific suggestions how you'd tackle this would be welcome.
(Technically, I see no other way than to change text and do another round of IA/review phase with the feedback we've received until now - if, based on the new background from AGM, everybody who has objected so far is now accepting this at it stands to go forward - please say so!)
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
Erik and all, I think your idea to exclude 16Bit ASN from the proposal brings us much closer to consensus. Nevertheless I think we should start discussing about how to "enhance" garbage collection, but this should IMHO not be part of discussion on _this_ proposal. BR Jens On 16.05.2015 09:11, Erik Bais - A2B Internet wrote:
Hi Gert,
There are a couple things that I keep reading and hearing in the discussion here..
Run-out of 16 bit as's and garbage collection..
May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence )
Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update.
The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at.
Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour.
Regards, Erik Bais
Verstuurd vanaf mijn iPad
Op 15 mei 2015 om 14:34 heeft Gert Doering <gert@space.net> het volgende geschreven:
Dear AP WG,
On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015.
So - we extended this to wait for the AGM decision on "charging for AS numbers". The AGM decided, and the clear majority decide to not introduce annual charges for AS numbers - my life would be easier otherwise, but this is what was decided, so respect it and see how we can achive our goals here :-)
Feedback for this proposal so far was, if I simplify a bit
- we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
- we might want a garbage collection / reclamation mechanism
- the current policy text is too complicate, arbitrary numbers are bad
but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check".
So, what should we (or, more precise, the proposers) do to get there?
Nick, I'm actually looking at you since you threw the most sand into the gears here... some specific suggestions how you'd tackle this would be welcome.
(Technically, I see no other way than to change text and do another round of IA/review phase with the feedback we've received until now - if, based on the new background from AGM, everybody who has objected so far is now accepting this at it stands to go forward - please say so!)
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
!DSPAM:637,5556f3e6233401397117280!
-- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
Hi, On Sat, May 16, 2015 at 12:26:15PM +0200, Opteamax GmbH wrote:
I think your idea to exclude 16Bit ASN from the proposal brings us much closer to consensus.
I should point out that 16bit ASNs are not currently subject of the proposal anyway... :-) But I did hear what Erik, Nick and David said, and there's a lot of wisdom in it. There will be a round of discussion with the proposers, and I see new text coming up, taking this into account. Gert Doering -- NetMaster -- 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
Hi Jens, As we are talking about AS numbers and implicit about BGP .. Lets take the following approach ... Ask the NCC to use a max-prefix kind of warning system in the hand-out / provisioning software .. A 95% warning level at ( arbitrary number 100 AS nr's ). To start asking questions on what the LIR is doing .. A full stop handing out at the 100% of the $arbitrary-number ... And the NCC will have to manually increase the number by another $amount. Same as every ISP does on an Internet Exchange with $peer that trips their max-prefix number .... That can be implemented in the backend .. And the majority of the LIR's will never trip the max-resource level .. But the ones that do .. Can be directed to the IPRA's and provide additional insight on what the hell they think they are doing ... And if they are not providing a sufficient use case that satisfies the IPRA, their request to increase the $arbitraty-number won't be increased ... So they can't request additional resources. This suggested deployment setup doesn't need to be put in stone in the policy, but as a request to the NCC in the introduction or rationale .. To keep the policy text clear and the NCC can reply to it in their IA .. Just my 2 cents ... Erik Bais. ( now a bit more awake that this morning ) ...
Op 16 mei 2015 om 12:26 heeft Opteamax GmbH <ripe@opteamax.de> het volgende geschreven:
Erik and all,
I think your idea to exclude 16Bit ASN from the proposal brings us much closer to consensus.
Nevertheless I think we should start discussing about how to "enhance" garbage collection, but this should IMHO not be part of discussion on _this_ proposal.
BR Jens
On 16.05.2015 09:11, Erik Bais - A2B Internet wrote: Hi Gert,
There are a couple things that I keep reading and hearing in the discussion here..
Run-out of 16 bit as's and garbage collection..
May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence )
Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update.
The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at.
Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour.
Regards, Erik Bais
Verstuurd vanaf mijn iPad
Op 15 mei 2015 om 14:34 heeft Gert Doering <gert@space.net> het volgende geschreven:
Dear AP WG,
On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015.
So - we extended this to wait for the AGM decision on "charging for AS numbers". The AGM decided, and the clear majority decide to not introduce annual charges for AS numbers - my life would be easier otherwise, but this is what was decided, so respect it and see how we can achive our goals here :-)
Feedback for this proposal so far was, if I simplify a bit
- we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
- we might want a garbage collection / reclamation mechanism
- the current policy text is too complicate, arbitrary numbers are bad
but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check".
So, what should we (or, more precise, the proposers) do to get there?
Nick, I'm actually looking at you since you threw the most sand into the gears here... some specific suggestions how you'd tackle this would be welcome.
(Technically, I see no other way than to change text and do another round of IA/review phase with the feedback we've received until now - if, based on the new background from AGM, everybody who has objected so far is now accepting this at it stands to go forward - please say so!)
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
!DSPAM:637,5556f3e6233401397117280!
-- Opteamax GmbH - RIPE-Team Jens Ott
Opteamax GmbH
Simrockstr. 4b 53619 Rheinbreitbach
Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de
HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
Hi Erik, I like that idea ... sometimes it might help to ask questions to make some LIRs start reflecting what they are actually doing. (But to be honest I prefer a single LIR requesting 100 ASN over a single person opening 100 LIRs, to bypass that rule and gather some IP-V4 as "side-effect" ;) ) @Gert: you are absolutely right when pointing it out that 16bit actually are already excluded explicitly ... think I was still to (amster)damaged when writing my last mail ... sorry ;) BR Jens On 16.05.2015 14:17, Erik Bais - A2B Internet wrote:
Hi Jens,
As we are talking about AS numbers and implicit about BGP .. Lets take the following approach ...
Ask the NCC to use a max-prefix kind of warning system in the hand-out / provisioning software ..
A 95% warning level at ( arbitrary number 100 AS nr's ). To start asking questions on what the LIR is doing .. A full stop handing out at the 100% of the $arbitrary-number ... And the NCC will have to manually increase the number by another $amount. Same as every ISP does on an Internet Exchange with $peer that trips their max-prefix number ....
That can be implemented in the backend .. And the majority of the LIR's will never trip the max-resource level .. But the ones that do .. Can be directed to the IPRA's and provide additional insight on what the hell they think they are doing ... And if they are not providing a sufficient use case that satisfies the IPRA, their request to increase the $arbitraty-number won't be increased ... So they can't request additional resources.
This suggested deployment setup doesn't need to be put in stone in the policy, but as a request to the NCC in the introduction or rationale .. To keep the policy text clear and the NCC can reply to it in their IA ..
Just my 2 cents ...
Erik Bais. ( now a bit more awake that this morning ) ...
Op 16 mei 2015 om 12:26 heeft Opteamax GmbH <ripe@opteamax.de> het volgende geschreven:
Erik and all,
I think your idea to exclude 16Bit ASN from the proposal brings us much closer to consensus.
Nevertheless I think we should start discussing about how to "enhance" garbage collection, but this should IMHO not be part of discussion on _this_ proposal.
BR Jens
On 16.05.2015 09:11, Erik Bais - A2B Internet wrote: Hi Gert,
There are a couple things that I keep reading and hearing in the discussion here..
Run-out of 16 bit as's and garbage collection..
May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence )
Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update.
The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at.
Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour.
Regards, Erik Bais
Verstuurd vanaf mijn iPad
Op 15 mei 2015 om 14:34 heeft Gert Doering <gert@space.net> het volgende geschreven:
Dear AP WG,
On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015.
So - we extended this to wait for the AGM decision on "charging for AS numbers". The AGM decided, and the clear majority decide to not introduce annual charges for AS numbers - my life would be easier otherwise, but this is what was decided, so respect it and see how we can achive our goals here :-)
Feedback for this proposal so far was, if I simplify a bit
- we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
- we might want a garbage collection / reclamation mechanism
- the current policy text is too complicate, arbitrary numbers are bad
but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check".
So, what should we (or, more precise, the proposers) do to get there?
Nick, I'm actually looking at you since you threw the most sand into the gears here... some specific suggestions how you'd tackle this would be welcome.
(Technically, I see no other way than to change text and do another round of IA/review phase with the feedback we've received until now - if, based on the new background from AGM, everybody who has objected so far is now accepting this at it stands to go forward - please say so!)
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
-- Opteamax GmbH - RIPE-Team Jens Ott
Opteamax GmbH
Simrockstr. 4b 53619 Rheinbreitbach
Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de
HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
!DSPAM:637,55573b8463551901918004!
-- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
Ask the NCC to use a max-prefix kind of warning system in the hand-out / provisioning software ..
perhaps there is a relevant lesson from recent discussions of ipv4 last /8 abuse randy
Op 16 mei 2015 om 19:13 heeft Randy Bush <randy@psg.com> het volgende geschreven:
Ask the NCC to use a max-prefix kind of warning system in the hand-out / provisioning software ..
perhaps there is a relevant lesson from recent discussions of ipv4 last /8 abuse
randy
We missed your insight at the meeting mic Randy ...
We missed your insight at the meeting mic Randy ...
i really missed being there we can blame serge, who shifted the meeting left one week from it's traditional time, and thus conflicted with our tenth wedding anniversary :) randy
participants (10)
-
Andreas Larsen -
Carlos Friacas -
David Huberman -
Erik Bais - A2B Internet -
Gert Doering -
Hamed Shafaghi -
Marco Schmidt -
Nick Hilliard -
Opteamax GmbH -
Randy Bush