Re: proposal for RIPE's IPv6-address space structure
To: JOIN Project Team <join@uni-muenster.de> Cc: ipv6-wg@ripe.net, lir-wg@ripe.net, Frank Hoffmeister <Frank.Hoffmeister@germany.eu.net>, ipv6@froggle.germany.eu.net, Juergen Rauschenbach <jrau@dfn.de> Subject: Re: proposal for RIPE's IPv6-address space structure From: Daniel Karrenberg <Daniel.Karrenberg@ripe.net> Date: Fri, 22 Nov 1996 16:01:56 +0100
JOIN Project Team <join@uni-muenster.de> writes:
Can you provide a rationale for grouping providers by country. It strikes me as contrary to both aggregation and conservation goals.
We assume that ISPs will mainly offer their service within one country.
This is not necessarily a valid assumption.
IBM offers Internet services in most European countries. It is not valid to assume that ISPs offer service mainly in one country. Ideally we would like to be given either a large block or multiple smaller ones so we can assign a block to each country and perform route summarisation internally within our OSPF cloud.
To: JOIN Project Team <join@uni-muenster.de> Cc: ipv6-wg@ripe.net, lir-wg@ripe.net, Frank Hoffmeister <Frank.Hoffmeister@germany.eu.net>, ipv6@froggle.germany.eu.net, Juergen Rauschenbach <jrau@dfn.de> Subject: Re: proposal for RIPE's IPv6-address space structure From: Daniel Karrenberg <Daniel.Karrenberg@ripe.net> Date: Fri, 22 Nov 1996 16:01:56 +0100
JOIN Project Team <join@uni-muenster.de> writes:
Can you provide a rationale for grouping providers by country. It strikes me as contrary to both aggregation and conservation goals
We assume that ISPs will mainly offer their service within one country .
This is not necessarily a valid assumption.
IBM offers Internet services in most European countries. It is not valid to assume that ISPs offer service mainly in one country. Ideally we would like to be given either a large block or multiple smaller ones so we can assign a block to each country and perform route summarisation internally within our OSPF cloud.
This is in line with the proposal. Even for internal use only, country related address blocks are handy for daily operations. The customers of multinational providers get nationalized addresses for the ease of internal and external routing (local peerings). Since each multinational vendor has a local company for operations having a country-related address block like any other (national) provider is perfectly in line.
Frank Hoffmeister <Frank.Hoffmeister@Germany.EU.net> writes:
This is in line with the proposal. Even for internal use only, country related address blocks are handy for daily operations. The customers of multinational providers get nationalized addresses for the ease of internal and external routing (local peerings). Since each multinational vendor has a local company for operations having a country-related address block like any other (national) provider is perfectly in line.
I agree if you use local in place of national and country. I pertinently do not agree if you confuse network topology with national borders. Grouping by country is not useful. Grouping by provider is. Sub-grouping within a provider can be. Daniel
Frank Hoffmeister <Frank.Hoffmeister@Germany.EU.net> writes:
This is in line with the proposal. Even for internal use only, country related address blocks are handy for daily operations. The customers of multinational providers get nationalized addresses for the ease of internal and external routing (local peerings). Since each multinational vendor has a local company for operations having a country-related address block like any other (national) provider is perfectly in line.
I agree if you use local in place of national and country. I pertinently do not agree if you confuse network topology with national borders. Grouping by country is not useful. Grouping by provider is. Sub-grouping within a provider can be.
Well, the original internal discussions used the term 'region' with countries being one possible instantiation :-) If you look at existing address blocks, then they have regional prefixes. Grouping by provider only, with random assignment of consecutive address blocks, counteracts the forming of regional prefixes. The question is: Do we need regionalized prefixes for scalable routing with IPv6 ? If YES, how do we form them ? If NO, how do we handle routing tables obeying a HUGE number of future providers ? Frank
participants (3)
-
Daniel Karrenberg -
Frank Hoffmeister -
Matt Fakray