RE: [lir-wg] Discussion about RIPE-261
At 01:29 AM 26-05-03 -0700, Michel Py wrote:
Needless to say, your numbers do not seem to take in any socio-economic factors. Assigning a /12 to North America as well as to Northern Africa and India might make socialistic sense as well as being "politically correct", but from a reality standpoint, it just don't fly.
It's politically impossible to assign socio-economic factors such as wealth. Who am I to pick a number and decide that Ethiopia gets 16 times less addresses that the US? If it is true that in the short term it would work, this would generate endless debates, which is why I picked that an Ethiopian gets the same number of IP addresses than an American.
So don't assign wealth. Use some number that has direct influence on IPv6 usage. Among the possibilities: - # of computer per capita - # of cellphones per capita - % of homes with electricity - % of homes with phone/cable - % of of homes with more than 5 electrical appliances Each would have a direct bearing on IPv6 usage. Pick any of the above or all of the above. -Hank
Hank Nussbacher said:
Needless to say, your numbers do not seem to take in any socio-economic factors.
So don't assign wealth. Use some number that has direct influence on IPv6 usage. Among the possibilities: - # of computer per capita [...]
IPv6 is supposed to last for what, 20 years? 30 years? 40 years? None of these assumptions is going to be valid in this timescale because you have no idea where the economies of countries are going to go. After all, in 1985 none of us would have assumed either the Soviet Union or China would have wanted any IP addresses at all. And people wouldn't even have heard of Kazakhstan. Either population or land area is about the best indicator you're going to get of *eventual* *long-term* demand. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646
Hi, On Mon, May 26, 2003 at 09:54:27AM +0100, Clive D.W. Feather wrote:
Either population or land area is about the best indicator you're going to get of *eventual* *long-term* demand.
I second that. (Hank, why are you opposing/questioning this approach? Are you worried about IPv6 space running out for the "high tech" countries?) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, 26 May 2003, Gert Doering wrote:
Hi,
On Mon, May 26, 2003 at 09:54:27AM +0100, Clive D.W. Feather wrote:
Either population or land area is about the best indicator you're going to get of *eventual* *long-term* demand.
I second that.
(Hank, why are you opposing/questioningthis approach?Are you worried about IPv6 space running out for the "high tech" countries?)
Reverse: are you worried that IPv6 space won't be available for non- "high-tech" countries when they will need it? -Hank
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations:54837 (54495)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Mon, May 26, 2003 at 05:14:48PM +0300, Hank Nussbacher wrote:
(Hank, why are you opposing/questioningthis approach?Are you worried about IPv6 space running out for the "high tech" countries?)
Reverse: are you worried that IPv6 space won't be available for non- "high-tech" countries when they will need it?
Not acutely worried. But then, *if* we decide to do some kind of distribution on the geographic level, we need to setup "chunks" in advance (to avoid having more than one high-level prefix per "region"). So this scheme should take future development into account - and who are we to say that a country X "will always be poor and under-developed"? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
"Clive D.W. Feather" wrote:
Hank Nussbacher said:
Needless to say, your numbers do not seem to take in any socio-economic factors.
So don't assign wealth. Use some number that has direct influence on IPv6 usage. Among the possibilities: - # of computer per capita [...]
IPv6 is supposed to last for what, 20 years? 30 years? 40 years? None of these assumptions is going to be valid in this timescale because you have no idea where the economies of countries are going to go. After all, in 1985 none of us would have assumed either the Soviet Union or China would have wanted any IP addresses at all. And people wouldn't even have heard of Kazakhstan.
Either population or land area is about the best indicator you're going to get of *eventual* *long-term* demand.
Am I the only one who thinks that geographical/population distribution of IP[v6] addresses is a flawed and evil concept in itself? The problem of IPv6 is that is has become an utopian kitchen sink. The current discussion about how to distribute the address space the "right" way is symptomatic for that. Why should an IP address have *any* kind of specific geographic meaning? Is it even smart to have that? Oh, you've got an IP address from Germany, we don't allow access to this server. Oh, you've got an IP address from China, we don't allow access to China critcal information (BBC server)... Can anyone tell me why an IP address should be geograhically significant in this way? Doesn't this open a can of worms of potential abuse all over the place? Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies??? Even countries change from time to time. See the split from .su to a whole bunch of .ru and so on. When does a "country" deserve it's own IP segement? Is for example Nothern Ireland a country is the sense of IPv6 address assignment? What about East-Timor? What if in 10 years northern Iraq is going to be the Republic of the Kurdes? Do they have to renumber from Iraq and Turkish addresses? What if in 20 years the European Union countries vote to become one nation? Do they have to renumber? Or will you assign by "federal state"? Why don't we just take the E.164 telephony numbering scheme and make IP addresses out of it? It's already country based! Not! What point does it make that we have got an IP address space so large so we can assign an IP number to every grain of sand on this planet if it can't keep the number? IPv6 has a number of fundamental design (I call it over-eager- engineering) flaws. All it should have done is to extend the address length, make the header fields fixed length and aligned. All the other stuff of creating a whole new way of doing networking like header stacking and so on is evil. Especially this does not belong into this layer. We've already got MPLS et al. Don't even get me started on putting routing information into DNS (IPv6 prefix in DNS)... shudder... -- Andre
Hi, On Mon, May 26, 2003 at 03:03:24PM +0200, Andre Oppermann wrote:
Can anyone tell me why an IP address should be geograhically significant in this way? Doesn't this open a can of worms of potential abuse all over the place?
One motivation I can see for it is to permit more-specific announcements inside a region (because it's interesting to find "the shortest way" to the destination network) but to summarize the routing information "from the outside". For us, as a small german ISP, it's not really important who is hooked up where in the US or in the AP region - so a summary route "all this stuff is in the US, send this to our upstream" (simplified) is likely to suit us fine. [..]
Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies???
Because nobody came up with a fix to the BGP scalability issues yet...? [..]
What point does it make that we have got an IP address space so large so we can assign an IP number to every grain of sand on this planet if it can't keep the number?
IPv6 routing, using todays technology, is only going to work if you can have enough hierarchy in the routing system. And yes, this means "renumber". (Apart from that, IPv6 is not about numbering grains of sand :) ) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, May 26, 2003 at 03:42:28PM +0200, Gert Doering wrote:
Hi,
On Mon, May 26, 2003 at 03:03:24PM +0200, Andre Oppermann wrote:
Can anyone tell me why an IP address should be geograhically significant in this way? Doesn't this open a can of worms of potential abuse all over the place?
One motivation I can see for it is to permit more-specific announcements inside a region (because it's interesting to find "the shortest way" to the destination network) but to summarize the routing information "from the outside".
So it should be a topological distinction, not geographical. If the Internet has taught us something so far it's geo space means *nothing*. Traffic from USA to Africa will likely go through Europe and in some cases be under EU IP space. However, in other cases with will be under ARIN IP space and go directly to Africa. How does that work with summarizing based on geo region ? Closer to home, I may have a LINX peering with Foo ISP but not with Bar ISP so my traffic goes Europe -> US West -> Europe. I am 4000km from both and they are spaced 20m.
For us, as a small german ISP, it's not really important who is hooked up where in the US or in the AP region - so a summary route "all this stuff is in the US, send this to our upstream" (simplified) is likely to suit us fine.
However for us, a smallish portuguese transit provider, it makes a whole of diference details like "where is hotmail.com connected" or "did google move ?" For small, simple setups where IPv4 0/0 is fairly enough this whole aggregation thing is just another detail. For people who actually do traffic engineering stuff like aggregation and geo-localization and (*gar*!) end-to-end route selection is just idiotic.
[..]
Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies???
Because nobody came up with a fix to the BGP scalability issues yet...?
isn't "memory is cheap" the mantra nowadays ?
[..]
What point does it make that we have got an IP address space so large so we can assign an IP number to every grain of sand on this planet if it can't keep the number?
IPv6 routing, using todays technology, is only going to work if you can have enough hierarchy in the routing system. And yes, this means "renumber".
Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system type ISPs to renumber if they change upstream provider. That will make you popular :) Now really, I rather have IPv6 now, evaluate the real practical problems and fix them than spending years not having IPv6 cause the fix to a would-be problem introduces unworkable problems itself. -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Hi, On Mon, May 26, 2003 at 03:29:10PM +0100, Carlos Morgado wrote:
Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system type ISPs to renumber if they change upstream provider. That will make you popular :)
If you have 500000 customers, there's no discussion that you can get your own address block (and keep it). The interesting problem is how to make end user (!) multihoming work without putting the burden on everybody *else*. I am NOT interested in seeing 20.000 small multihomed end customers in my routing tables, because in the end everything goes over one of two possible links anyway.
Now really, I rather have IPv6 now, evaluate the real practical problems and fix them than spending years not having IPv6 cause the fix to a would-be problem introduces unworkable problems itself.
So go and get an allocation :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, May 26, 2003 at 04:35:09PM +0200, Gert Doering wrote:
Hi,
On Mon, May 26, 2003 at 03:29:10PM +0100, Carlos Morgado wrote:
Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system type ISPs to renumber if they change upstream provider. That will make you popular :)
If you have 500000 customers, there's no discussion that you can get your own address block (and keep it).
Granted, that example was a bit extreme :) However, most ISPs/networks tend to fiercely opose renumbering.
The interesting problem is how to make end user (!) multihoming work without putting the burden on everybody *else*. I am NOT interested in seeing 20.000 small multihomed end customers in my routing tables, because in the end everything goes over one of two possible links anyway.
That's cause you only have 2 links. Some people have 20. With 3 diferent routing policies. And that's not even counting costumer links. Geting the Americas, Africa, Europe and Asia routes blows dead bears in that situation.
Now really, I rather have IPv6 now, evaluate the real practical problems and fix them than spending years not having IPv6 cause the fix to a would-be problem introduces unworkable problems itself.
So go and get an allocation :-)
Aparently I'm not big enough. My costumers are though. I'm supposed to get a /48 from one my 5 or 6 upstream providers and then announce it to a number of IXs. It's got to be a brave new Internet when in the name of aggregation upstream providers can't get address space. (but that's another flamewar ;)) -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Hi, On Mon, May 26, 2003 at 03:56:36PM +0100, Carlos Morgado wrote: [..]
The interesting problem is how to make end user (!) multihoming work without putting the burden on everybody *else*. I am NOT interested in seeing 20.000 small multihomed end customers in my routing tables, because in the end everything goes over one of two possible links anyway.
That's cause you only have 2 links. Some people have 20. With 3 diferent routing policies. And that's not even counting costumer links. Geting the Americas, Africa, Europe and Asia routes blows dead bears in that situation.
As I've already replied to Daniel Roesen: if you're big enough, you might need to carry even the far-distant more specifics. But then you need to buy "the big routers" anyway, just due to interface speed reasons. And again: not wanting to do something doesn't mean you have to take away the possibility to do so from everybody else, unless there is good technical reason against it. [..]
So go and get an allocation :-)
Aparently I'm not big enough. My costumers are though.
Have you sent in a formal request to the RIPE hostmasters?
I'm supposed to get a /48 from one my 5 or 6 upstream providers and then announce it to a number of IXs. It's got to be a brave new Internet when in the name of aggregation upstream providers can't get address space. (but that's another flamewar ;))
I'm not going to revive that discussion - this *is* why we're working on the policy (on the global-v6 list) and have the proposal to change the "200 customers" requirement. Right now we're talking about a specific proposal (RIPE-261) and should try to keep the discussion focused. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, May 26, 2003 at 05:03:32PM +0200, Gert Doering wrote:
As I've already replied to Daniel Roesen: if you're big enough, you might need to carry even the far-distant more specifics. But then you need to buy "the big routers" anyway, just due to interface speed reasons.
No, more or less every BGP customer wants full routes. You assume that BGP customers with smallish bandwidths don't have a need for really _full_ routes. I think quite the contrary is true... the smaller the customer, the more he wants/needs to do traffic engineering. Best regards, daniel
Hi, On Mon, May 26, 2003 at 05:46:53PM +0200, Daniel Roesen wrote: [..]
No, more or less every BGP customer wants full routes. You assume that BGP customers with smallish bandwidths don't have a need for really _full_ routes. I think quite the contrary is true... the smaller the customer, the more he wants/needs to do traffic engineering.
I'm not going to argue that now, because that's a decision everybody has to do for his network - and if his customers do not like that, they will go to the competition. Nevertheless, let's get back to the basic question - how shall we go ahead: [ ] continue the IANA->RIR->LIR allocation as it is now [ ] accept RIPE-261 [ ] allocate bigger chunks IANA->RIR (/8 ?) and inside those chunks, use a binary chop algorithm similar to the one described in RIPE-261 [ ] go for a full multi-level regional distribution, down to "one /32 per LIR per country" (as detailed by Michael Py) [ ] something else I do like a good rant as much as anybody else, but "BGP is broken" and "you don't understand the way the Internet will work in 10 years" will not really help us *get there*. So please try to confine the discussion to this topic, and try to get consensus how to move on. There's no way to solve all problems in one big step. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
[ ] continue the IANA->RIR->LIR allocation as it is now
No.
[ ] accept RIPE-261
Yes.
[ ] allocate bigger chunks IANA->RIR (/8 ?) and inside those chunks, use a binary chop algorithm similar to the one described in RIPE-261
Yes.
[ ] go for a full multi-level regional distribution, down to "one /32 per LIR per country" (as detailed by Michael Py)
No.
I do like a good rant as much as anybody else, but "BGP is broken" and "you don't understand the way the Internet will work in 10 years" will not really help us *get there*. So please try to confine the discussion to this topic, and try to get consensus how to move on.
Agreed. The flaws of IPv6 comes down to not solving the multihomign/routing scaling/world starvation problem. That is an IETF problem, and there is a WG for it. (Ok, so I took the opportunity to do some marketing). - kurtis -
Ordered from the most preferable to the least preferable. On Mon, 26 May 2003, Gert Doering wrote:
[ ] something else
Something else: allocate bigger chunks IANA->RIR and allocate as before. That seems pretty close to the third option.
[ ] allocate bigger chunks IANA->RIR (/8 ?) and inside those chunks, use a binary chop algorithm similar to the one described in RIPE-261
So this is the second preference, I guess (but there is not enough detail to say whether the binary chop etc. is actually what we want.)
[ ] continue the IANA->RIR->LIR allocation as it is now
Current is OK, except IANA gives way too small blocks.
[ ] accept RIPE-261
Whole 2000 seems like a lot, and I fail to see any need to lose the RIR separation here.
[ ] go for a full multi-level regional distribution, down to "one /32 per LIR per country" (as detailed by Michael Py)
This seems to have issues e.g. for multinational LIR's as well as when new countries are born and die. But maybe the issues could be worked out.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Mon, May 26, 2003 at 03:29:10PM +0100, Carlos Morgado wrote:
Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies???
Because nobody came up with a fix to the BGP scalability issues yet...?
isn't "memory is cheap" the mantra nowadays ?
RAM is only a problem for some vendor's gear. The main problem is route convergence. BGP is designed with two assumptions in mind: - many routes - fairly stable topology The more routes, the higher the convergence times... and this is does not scale linear.
Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system type ISPs to renumber if they change upstream provider. That will make you popular :)
:-) Regards, Daniel
On Mon, May 26, 2003 at 03:42:28PM +0200, Gert Doering wrote:
For us, as a small german ISP, it's not really important who is hooked up where in the US or in the AP region - so a summary route "all this stuff is in the US, send this to our upstream" (simplified) is likely to suit us fine.
But you will still need to carry the routes in order to support your BGP customers. I doubt that they will be happy with upstream's vision of aggregation at all times... Best regards, Daniel
Hi, On Mon, May 26, 2003 at 04:32:14PM +0200, Daniel Roesen wrote:
On Mon, May 26, 2003 at 03:42:28PM +0200, Gert Doering wrote:
For us, as a small german ISP, it's not really important who is hooked up where in the US or in the AP region - so a summary route "all this stuff is in the US, send this to our upstream" (simplified) is likely to suit us fine.
But you will still need to carry the routes in order to support your BGP customers. I doubt that they will be happy with upstream's vision of aggregation at all times...
Well, yes. If you move up high enough in the routing hierarchy, your downstream customers might want that information, and then you have to carry full tables. Nevertheless I see no good reason to take this option away from people that might benefit from it. If you don't want to use it, there's no big difference in doing the allocations "by regions" (however they might look in the end - I'm not talking about countries, and yes, some border line problems exist) or "just across all regions". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering wrote:
Hi,
On Mon, May 26, 2003 at 03:03:24PM +0200, Andre Oppermann wrote:
Can anyone tell me why an IP address should be geograhically significant in this way? Doesn't this open a can of worms of potential abuse all over the place?
One motivation I can see for it is to permit more-specific announcements inside a region (because it's interesting to find "the shortest way" to the destination network) but to summarize the routing information "from the outside".
How often did your routing policy change over the last seven years? How often do you point a default route towards one of your upstreams? Does is matter if only a holy batch of ISPs are allowed to run real routing at all? Since when has geography anything to do with network topology? Routing is not about the shortest path, it's about the cheapest path along the policies of the AS it is passing through?
For us, as a small german ISP, it's not really important who is hooked up where in the US or in the AP region - so a summary route "all this stuff is in the US, send this to our upstream" (simplified) is likely to suit us fine.
Yes, not every ISP is a small german ISP... You try to fix an routing protocol issue at the network level. Major mistake. Things like this are normally not handled on the data plane, they are handled on the control plane. Which means routing protocol. So we are back at BGP.
[..]
Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies???
Because nobody came up with a fix to the BGP scalability issues yet...?
Hmmm... Moore's law? If I remember correctly ten years ago your average (backbone) router had a Mbyte of RAM. Today 128MB is average and more 256MB is quite commmon. CPUs have also come a great way since then. Effectively there is nothing preventing a global BGP routing system from having 500'000 prefixes and 65'000 AS (except of course the price tag of a Cisco box with some old M68k processor). We don't have a BGP scalability issue as such at all. We are now at BGPv4, which means there have been some previous iterations in the matrix. What do we need for BGPv5? More AS numbers. What else? More CPU and more RAM to store more AS number and IP prefixes.
[..]
What point does it make that we have got an IP address space so large so we can assign an IP number to every grain of sand on this planet if it can't keep the number?
IPv6 routing, using todays technology, is only going to work if you can have enough hierarchy in the routing system. And yes, this means "renumber".
And how is that different from IPv4 + NAT? I hardly see any IPv6 "routing system" at all. You are making a very big mistake by just looking at today's structure and needs. Going from there is never giving you a scaleable and adaptive network for the future. Why don't you take your current IPv6 ideas and (virtually) put them on top of the Internet ten years ago? See what happens? Keep everything on it's level and don't move routing policy from the policy level to the forwarding level. It won't work. Also have a look at every month of the last 10 years. Watch how the Internet, the link capacity, the CPU power, the memory sizes and so on have developed. How many times had the harddisk bus IDE/ATA to be extended to acomodate the new drive capacities? In 1993 I was the proud owner of a i386sx16MHz PC with 1MB of RAM. Today I've got two GB of RAM in the very PC I'm writing this email on. What the heck, I've could even stick four GB in there, it's only 320 nowadays. About the price of an average high level 3d graphics card for gaming. The hardest thing is always to stick to the simplest principles. That is why so many greatly engineered things fail. What has made the current IPv4 Internet scale to the level we see today? I'm not only talking about the routing but also new applications like WWW/HTTP, Napster, Peer-to-Peer and so on. Think about it and see how many of those simple principles are being broken by todays IPv6 state of affairs (plus all the nice proposals out there for fixing problems we didn't even had before)?
(Apart from that, IPv6 is not about numbering grains of sand :) )
Ok, but what is it about then? I haven't found an advantage of IPv6 over IPv4 yet that would gain me anything (easy of use, cheaper, less work, etc). -- Andre
Hello, I know I'm responding to an old email, but I can't resist pointing out a small but common fallacy here: Quote from Andre Oppermann: } In 1993 I was the } proud owner of a i386sx16MHz PC with 1MB of RAM. Today I've got two } GB of RAM in the very PC I'm writing this email on. What the heck, } I've could even stick four GB in there, it's only EUR320 nowadays. } About the price of an average high level 3d graphics card for gaming. Routers -- and especially L3-switch-routers -- tend to use content addressable memory (CAM) or other such specialized architectures instead of dynamic random access memory (DRAM) to store the forwarding table on NICs. The production numbers of DRAM chips are orders of magnitude larger than those of CAM chips, and the gap is getting bigger. These technologies are also way more complex than DRAM to begin with. This means that the same amount of memory takes up a lot more silicon real estate which is exponentially relative to chip cost. Using just DRAM is not an option either because you cannot build the whole Internet on small-to-medium size routers with slow line cards. Some operators will always outgrow them and those operators will be the ones who in the end dictate how things are done. This doesn't actually have anything to do with my personal view on routing table growth. I'm just saying that there is a real technical reason to be worried about it. CAMs (et al.) are getting larger every year of course but, to the best of my knowledge, they are not doubling in size every year as per Moore's law. To quote Frederick Brooks, I don't think there will be a silver bullet to this problem. -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting
Can anyone tell me why an IP address should be geograhically significant in this way? Doesn't this open a can of worms of potential abuse all over the place?
One motivation I can see for it is to permit more-specific announcements inside a region (because it's interesting to find "the shortest way" to the destination network) but to summarize the routing information "from the outside".
For us, as a small german ISP, it's not really important who is hooked up where in the US or in the AP region - so a summary route "all this stuff is in the US, send this to our upstream" (simplified) is likely to suit us fine.
The problem is then just moved to a) Maintaining your filters b) Maintaining the allocations at the RIR level c) Renumbering d) What happens if you want to tweak your routing policies? e) Your upstream need to carry all the routes if you want to achieve d)
[..]
Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies???
Because nobody came up with a fix to the BGP scalability issues yet...?
With multi6 chair hat on I would say the problem is the opposite. However, we have yet to start working on the overall architecture. But that looks like it might start to happen as well. - kurtis -
On måndag, maj 26, 2003, at 15:03 Europe/Stockholm, Andre Oppermann wrote:
Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies???
Well said. The problem is that IPv6 doesn't address the problems we are having and we are trying to patch and paint it over with complex allocation policies. Let's fix the problem instead. - kurtis -
participants (9)
-
Aleksi Suhonen -
Andre Oppermann -
Carlos Morgado -
Clive D.W. Feather -
Daniel Roesen -
Gert Doering -
Hank Nussbacher -
Kurt Erik Lindqvist -
Pekka Savola