Hi Andrew,
On 2/12/07, Andrew Alston <[EMAIL PROTECTED]> wrote:
Hi All, Ok, I think with regards to the points below, I think it's important to state the case from the other side of the fence. I'm going to attempt to address each of the points mentioned below, as I view things rather differently, and perhaps we can get more discussion going about this, as I do think that more discussion is always productive.
Yes, by all means, I'd like to hear from those African LIRs who have some IPv6 deployment experience especially.
A.) Creation of swamp space I strongly believe that P.I space needs to be allocated out of a fixed single block, the size of that block is debatable, but by doing this we avoid the creation of large segments of swamp space, it's a limited block. It also allows for the filtering of the smaller blocks from outside of the P.I block, which keeps filtering manageable. I don't think that taking this method, the swamp space argument is really one of concern in my mind.
Well of course, if we are going to do it, let's keep it small, but I would prefer giving /32's (a la proposal in RIPE region) rather than /48 (policy in ARIN region). Small in v6 is on a different scale than in IPv4 world ;-)
B.) Routing table bloat I've had this discussion with many people, in many parts of the world, and come to the following conclusions: 1.) The routing table growth has never come close to keeping up the increases in processing power and memory considerations of modern routers, I'm not at all convinced that we need to worry about this in terms of hardware.
This is the "Moore's Law argument", which while perhaps true, would still have significant cost implications for most providers. (see latest Nanog mtg archives links below for discussion on pushing the FIB limits) http://www.nanog.org/mtg-0702/jaeggli.html http://www.nanog.org/mtg-0702/presentations/fib-editorial.pdf http://www.nanog.org/mtg-0702/presentations/fib-hankins.pdf http://www.nanog.org/mtg-0702/presentations/fib-desilva.pdf http://www.nanog.org/mtg-0702/presentations/fib-ryan.pdf http://www.nanog.org/mtg-0702/presentations/fib-scudder.pdf (2 million routes!) http://www.nanog.org/mtg-0702/presentations/fib-atkinson.pdf http://www.nanog.org/mtg-0702/presentations/smith-lightning.pdf (Slides 9 & 10 talk about Africa)
2.) Due to the size of IPv6 blocks, even if we take into consideration companies using multiple blocks for the sake of aggregation,
I'm lost here, why would companies using multiple blocks for the "sake" of aggregation? the number
of P.I IPv6 blocks being announced by a single company should be significantly less than the number of P.I IPv4 blocks, purely because a company that gets a /48 today can expand hugely with that block, versus a small company that gets a /24 today, and needs another /24 tomorrow, purely because of the allocation policies today which require people to justify the space they are applying for. With these two considerations in mind, in my mind, I'm not convinced this is a concern at all.
I guess it's a matter of economics, why does company "y" need to upgrade routers so companies "a thru m" can get PI space? This is the oft- invoked tragedy of the commons that we face(d) in the v4 world.
C.) Demand for IPv6 PI Space. At the moment we cannot really evaluate this, as lets face it, there isn't much demand for IPv6 at all yet. As the need for redundancy, the need for multi-homing,
which isn't yet "sorted" in v6, but will need to be (id/locator split ?) and the need for companies to be able to be more
mobile in their provider choices increases, this demand could very easily become apparent.
This type of renumbering is supposed to be a design feature of IPv6. Provider lock-in is bad for consumers, IPv6 is supposed to make this less of an issue.
D.) The RIR Revenue stream First of all, it's my strong opinion that if an RIR has to resort to denying a service to the public in order to grow its revenue, there is a much larger problem than the problem of if the service should or shouldn't be provided.
It's not a service IMHO, it's a design issue of the numbering scheme. The IETF folk who designed IPv6 parameters discarded the notion of PI to improve aggregation. It's a fundamental aspect of the numbering scheme. I reckon we ought to tread quite carefully down this path. I believe that it is fundamentally flawed to
base the decision to allow or disallow P.I IPv6 space based on revenue.
It's not the basis of my thinking, just a consideration.
Are there not enough problems in the African Internet community with regards insanely high costs, without attempting to find reasons to force ISP's who are already burdened with high costs to pay even more money?
There are more than enough ;-( These ISPs can get a sub-allocation from an LIR if they wish.
Yes, I fully understand that an RIR must be financially viable, but I really do not think that this decision should be based on the RIR's economics. After all, an RIR is a non-profit entity, and while it has running costs, there is a difference between growing revenue to stay sustainable and defining policies based on generation of funds at the expense of the community for which the organization was created to serve.
Correct, policies should be based on what the community needs. I just don't see the "need" here, yet. I think that revenue implications should be kept in the back of the mind during these discussions though. My thinking on IPV6 PI has changed somewhat over the last few months, as the genie is already "out of the bottle", so to speak. If we do go down this path, I too would like to see a much broader discussion,(involving more ppl on this list). -- Cheers, McTim $ whois -h whois.afrinic.net mctim _______________________________________________ rpd mailing list [email protected] https://lists.afrinic.net/mailman/listinfo.cgi/rpd
