Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 2/27/15 17:41 , Dean Pemberton wrote:
On Sat, Feb 28, 2015 at 8:03 AM, David Farmer farmer@umn.edu wrote:
Don't allocated one if they don't want one. But if they want one, and they already have PI, or getting new PI, then why say no? And its not regardless of need, more accurately in anticipation of future need.
Nope - you almost had me, but now you've lost me again, well done.
Sorry, let me try one more time.
What you are suggesting *IS* regardless of need, and thats what I think people are missing. If you are not required to demonstrate need to get something, then it is allocated regardless of need. I realise this might seem semantic, but policy is all about semantics.
On this we agree.
This 'anticipation of future need' stuff is at best ethereal and at worst a fallacy. Lets not forget that there is an almost zero barrier to entry with regard to ASN allocation should the member require one. I just don't subscribe to this "I may one day require one so give it to me now"
If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing.
It's the same as saying "I don't require an IPv6 allocation today, but I anticipate that at some point I'll need a /10. Just give it all to me now so that I don't have to make difficult design decisions later."
If everyone gets one then I can live with that. What I can't live with is opening up a can of worms with a "I might one day need something so please allocate it now". It's a dangerous slippery slope. Today ASNs, Tomorrow IPv4, next day IPv6.
It's not that I only might need it, in my opinion it is fundamentally necessary to fulfill the portability of the PI assignment. No need to move the assignment within the routing system, no need for portability and no need for an ASN. But, if you make a PI assignment without allowing me an ASN you've limited its portability and the useability for its intended purpose. Making a PI assignment implies to me, it can be picked up and moved within the routing system, assigning an ASN is needed to facilitate that movement.
However, looked at through the lens of multi-homing, portability itself is only a future need. You have to look beyond multi-homing, not abandon the idea of need, to understand what I'm trying say.
But, I probably only dug the whole deeper. :) So, I'll stop now.
So it's back to what I said originally. You're claiming that an ASN is required in order to be a fully fledged member of the PI utilising community. You're also claiming that an ASN isn't an operational element anymore, that it's more like a license to be able to use PI space to it's fullest extend.
If it is true, then the only sensible way forward is to allocate them as you become a community member.
So we're back to "Become an APNIC member, get an ASN"
Is that really what people are saying and is it really a sensible thing 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 Sat, Feb 28, 2015 at 10:08 AM, David Farmer farmer@umn.edu wrote:
On 2/27/15 17:41 , Dean Pemberton wrote:
On Sat, Feb 28, 2015 at 8:03 AM, David Farmer farmer@umn.edu wrote:
Don't allocated one if they don't want one. But if they want one, and they already have PI, or getting new PI, then why say no? And its not regardless of need, more accurately in anticipation of future need.
Nope - you almost had me, but now you've lost me again, well done.
Sorry, let me try one more time.
What you are suggesting *IS* regardless of need, and thats what I think people are missing. If you are not required to demonstrate need to get something, then it is allocated regardless of need. I realise this might seem semantic, but policy is all about semantics.
On this we agree.
This 'anticipation of future need' stuff is at best ethereal and at worst a fallacy. Lets not forget that there is an almost zero barrier to entry with regard to ASN allocation should the member require one. I just don't subscribe to this "I may one day require one so give it to me now"
If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing.
It's the same as saying "I don't require an IPv6 allocation today, but I anticipate that at some point I'll need a /10. Just give it all to me now so that I don't have to make difficult design decisions later."
If everyone gets one then I can live with that. What I can't live with is opening up a can of worms with a "I might one day need something so please allocate it now". It's a dangerous slippery slope. Today ASNs, Tomorrow IPv4, next day IPv6.
It's not that I only might need it, in my opinion it is fundamentally necessary to fulfill the portability of the PI assignment. No need to move the assignment within the routing system, no need for portability and no need for an ASN. But, if you make a PI assignment without allowing me an ASN you've limited its portability and the useability for its intended purpose. Making a PI assignment implies to me, it can be picked up and moved within the routing system, assigning an ASN is needed to facilitate that movement.
However, looked at through the lens of multi-homing, portability itself is only a future need. You have to look beyond multi-homing, not abandon the idea of need, to understand what I'm trying say.
But, I probably only dug the whole deeper. :) So, I'll stop now.
--
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 ================================================
On 28/Feb/15 03:08, David Farmer wrote:
If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing.
True, PI is meant to be portable, which is fine for IPv6 because we have a lot of address space.
But don't you worry that you will blow through 4.2 billion ASN's soon if PI allocation policy evolves to become liberal that 4.2 billion PI allocations become a reality?
Mark.
On Feb 27, 2015, at 21:28, Mark Tinka mark.tinka@seacom.mu wrote:
On 28/Feb/15 03:08, David Farmer wrote:
If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing.
True, PI is meant to be portable, which is fine for IPv6 because we have a lot of address space.
But don't you worry that you will blow through 4.2 billion ASN's soon if PI allocation policy evolves to become liberal that 4.2 billion PI allocations become a reality?
Mark.
If IPv6 PI allocations gets too liberal, the routing system as we know it will implode long before we allocate 4.2 billion ASNs. Restricting the number of ASNs in use in the routing system isn't really going to help that much. The total number of prefixes, PA or PI, has been the primary limiting factor historically. Limiting the portability of PI prefixes by not allocating ASNs won't save the routing system. Only ensuring that the growth in the number of prefixes, both PA and PI, is sustainable and doesn't exceed the growth in the prefix limit for the typical router in use in the Internet at any point in time will keep the current routing system going.
We need a new kind of routing system, we've known that for a while. But that is not a policy issues for the RIRs, that is a technology issues for the IETF and the IRTF. I think things like LISP and ILNP are promising in the long run. We just have to keep the current routing system going until those technologies can prove themselves. We do that by keeping total prefix growth sustainable, not by limiting portability of PI prefixes.
On 28/Feb/15 08:07, David Farmer wrote:
If IPv6 PI allocations gets too liberal, the routing system as we know it will implode long before we allocate 4.2 billion ASNs. Restricting the number of ASNs in use in the routing system isn't really going to help that much. The total number of prefixes, PA or PI, has been the primary limiting factor historically. Limiting the portability of PI prefixes by not allocating ASNs won't save the routing system. Only ensuring that the growth in the number of prefixes, both PA and PI, is sustainable and doesn't exceed the growth in the prefix limit for the typical router in use in the Internet at any point in time will keep the current routing system going.
My lack of support of being willy-nilly with ASN allocations has nothing to do with the state (or decline) of routing system. It's not IP addresses' or ASN's fault that the community de-aggregates the way it does.
So while this is a valid concern, it does not take away from the fact that ASN's are finite, and IMHO, should not be allocated linearly with PI space "just because".
If there is policy that supports linear allocation between PI and ASN resources that makes sense, I'm more than happy to support such policy. As of now, there isn't such policy, and without such policy, current policy is good enough.
We need a new kind of routing system, we've known that for a while. But that is not a policy issues for the RIRs, that is a technology issues for the IETF and the IRTF. I think things like LISP and ILNP are promising in the long run. We just have to keep the current routing system going until those technologies can prove themselves. We do that by keeping total prefix growth sustainable, not by limiting portability of PI prefixes.
This ties back to what I was saying about, in general, getting the RIR and operational community to develop policies, together, which track practical day-to-day experiences about running IP networks. But that is a discussion for another thread, or as we shall experiment, which operators get involved in the policy development process.
Mark.
Activity Summary
- 2950 days inactive
- 2950 days old
- sig-policy@lists.apnic.net
- 3 participants
- 4 comments