Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 22-nov-04, at 17:53, Mohacsi Janos wrote:
And don't forget that you still have to change your phone number when you move a great enough distance. In IP we somehow feel it's important that there are no geographical constraint on address use at all. That's a shame, because even if we aggregate by contintent that would save up to four times in the number of entries in the routing table of any router.
Then why geographic based aggregated IPv6 addresses disposed? Geographic based addresses can solve the agregation quite nicely.
The general objection (apart from incorrect assumptions based on old incomplete work) is that network topology and geography don't correlate. My counter-objection is that the correlation doesn't have to be 1 to be able to take advantage of it when it's present.
Unfortunately the uniqueness can be problematic....
How do you mean?
On Mon, 22 Nov 2004 21:28:06 +0100, Iljitsch van Beijnum said:
The general objection (apart from incorrect assumptions based on old incomplete work) is that network topology and geography don't correlate. My counter-objection is that the correlation doesn't have to be 1 to be able to take advantage of it when it's present.
On the other hand, unless you have some way to *enforce* a higher correlation than we already have, how do you propose to get a better result than we currently (mostly accidentally) get via CIDR aggregation? For instance, 212.x.y.z is "known" to be on one continent, and so on - but how do you leverage that into a 212/8 routing entry?
On 22-nov-04, at 21:42, Valdis.Kletnieks@vt.edu wrote:
that network topology and geography don't correlate. My counter-objection is that the correlation doesn't have to be 1 to be able to take advantage of it when it's present.
On the other hand, unless you have some way to *enforce* a higher correlation than we already have, how do you propose to get a better result than we currently (mostly accidentally) get via CIDR aggregation?
There is no enforcing as such. All the gory details are in http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr -01.txt
For instance, 212.x.y.z is "known" to be on one continent, and so on - but how do you leverage that into a 212/8 routing entry?
Well, suppose we know 212/8 is used in Europe. A network that is present in say, North America and Europe then has the routers in Europe that talk to the routers in America filter out all 212/8 more specifics and only announce the aggregate instead. In the simple version this only works if there is full interconnection for all 212/8 destination in Europe. In the more complex version there is selective deaggregation for some destinations to overcome lack of local peering.
iljitsch@muada.com (Iljitsch van Beijnum) wrote:
For instance, 212.x.y.z is "known" to be on one continent, and so on - but how do you leverage that into a 212/8 routing entry?
Well, suppose we know 212/8 is used in Europe. A network that is present in say, North America and Europe then has the routers in Europe that talk to the routers in America filter out all 212/8 more specifics and only announce the aggregate instead. In the simple version this only works if there is full interconnection for all 212/8 destination in Europe.
And if everyone gives transit to anyone. Ideal world. Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On 23-nov-04, at 11:09, Elmar K. Bins wrote:
Well, suppose we know 212/8 is used in Europe. A network that is present in say, North America and Europe then has the routers in Europe that talk to the routers in America filter out all 212/8 more specifics and only announce the aggregate instead. In the simple version this only works if there is full interconnection for all 212/8 destination in Europe.
And if everyone gives transit to anyone. Ideal world.
Actually everyone giving everyone transit is far from ideal. We've seen this happen in IPv6, with poor performance as a result. The trouble is that the destination of the traffic can do very little to improve this even if good connectivity is also present. But that's not what I'm saying anyway. If aggregates are only used within ASes and not communicated to other ASes, the macro view will stay the same. We just remove information in places where it has no added value. For example, someone in Los Angeles really doesn't care whether a packet goes to Darmstadt or Hannover. All they care about is that the packets move to the east. The correlation between network topology and geography doesn't have to be perfect. The number of routing table entries saved corresponds to the level of topology/geo correlation. Anything from 50% and up would be worthwhile, IMO.
participants (3)
-
Elmar K. Bins -
Iljitsch van Beijnum -
Valdis.Kletnieks＠vt.edu