Re: (IPng 5002) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard
On Dec 2, 4:48am, bmanning@isi.edu wrote:
In short, I differ from Mike in that my values for "believed to be viable" differ, apparently wildly, from his and brians. I'm unconvinced that this will remain a true, long term technological argument. I'd like to see something besides, "too hard with 1990's technologies". "Long time" ought to have a better spec than say, Internet Dog Years?
Bill, What you say is true. Technology is going to progress, and at some point in the future we may convince ourselves that we can safely handle 1,000,000 TLAs instead of 10,000. However: 1) We are not there yet. Andrew Brodnik et al demonstrated that one can efficiently compress today's routing tables in the cache of a Pentium chip. But their algorithm has yet to be implemented in commercial routers. 2) There is more to scaling than routers' caches. Compressing the tables in cache memory mainly allows you to switch packets faster than if your tables were kept in a slow RAM. It does not reduce route flaps, or the complexity of the topology. 3) In any case, we are taking decision today based on today's technology. As I pointed out, there is plenty of address space reserved for further use. If the technology does evolve, then it will be time to open more space. In short, limiting the size of TLA to 13 bits looks like a reasonable cut, today. -- Christian Huitema
1) We are not there yet. Andrew Brodnik et al demonstrated that one can efficiently compress today's routing tables in the cache of a Pentium chip. But their algorithm has yet to be implemented in commercial routers.
True. But how far off can that be? :)
2) There is more to scaling than routers' caches. Compressing the tables in cache memory mainly allows you to switch packets faster than if your tables were kept in a slow RAM. It does not reduce route flaps, or the complexity of the topology.
One of the interesting side effects from the paper is the construct that appears to allow the creation of a true default free router i.e. one that has the ability to carry the total IPv4 space as host routes. a 13bit TLA does not reduce route flap nor moderate the complexity of the topology, which appear to have moved into the critical path. a 13bit TLA does give some breathing room by sanctioning a level of proxy aggregation. This method allows ISPs to lie to each other about the stability of their internal infrastructure, which is the current model for reducing the dynamics of the routing system. (Is it just me or is there really a joke being perpetrated by the attempts to present a stable routing infrastructure with dynamic routing protocols? :)
3) In any case, we are taking decision today based on today's technology. As I pointed out, there is plenty of address space reserved for further use. If the technology does evolve, then it will be time to open more space.
Fine. Then this might be best served as a BCP and not standards track? Or are the concerns rasied by everyone but me strong enough to push this into the standards track? What I find interesting is that this particular addressing scheme has had less field time than the previous addressing scheme. Will there be yet another scheme fall out of the woodwork? Is there a reason why these schemes can't co-exist? And I'm not sure that the extra space will be available. Are you?
In short, limiting the size of TLA to 13 bits looks like a reasonable cut, today.
Ok. I just thought I'd say my piece.
-- Christian Huitema
-- --bill
In short, limiting the size of TLA to 13 bits looks like a reasonable cut, today.
I want to add that for the TLA and AAAA record discussion I see nothing wrong with having a stage 1 solution and then stage 2 and we create the backwards compatibility as implementors. I realize we need to provide the best solution for dynamic addressing and for ISPs. But right now real customers want IPv6 on "Intranets", or private enterprises. We will see several products this year and customers will be able to start deploying IPv6 from vendors. Many customers do not want to move to private addresses and a total v4 NAT solution who need addresses today. They want to move to IPv6 and have a plan to participate on the Internet even before the ISPs start supporting their needs for IPv6. I will also say that Europe and Asia appear to be moving much faster than the U.S. ISPs to be IPv6 ready. The point of this mail is that we implementors of IPv6 can absorb updates to the Address Architecture and AAAA records and we have changed the addr arch twice and once enough where we updated our code on the 6bone, and are using the new specs. The implementors will do the changes we develop and that should not be a fear of anyone IMO. The essential architecture of IPv6 is done and most of us have our code base prep'd to support the evolutionary IPv6 fine tuning by this working group. It is not difficult to move forward here with changes. One of the things that has always driven the IETF processes is the "market". There is now a market for IPv6 and they want it right now. We need to give it to them as vendors, and I hope we view that need in our deliberations. Also we have some new players at the UNH bake-off this week and one of them is Microsoft. This is really good. /jim
participants (3)
-
bmanning＠ISI.EDU -
bound＠zk3.dec.com -
huitema＠bellcore.com