BCP for multisite multihoming

[Peter Sherbin]

> The size of the address block for a city and its surroundings is determined by  
> taking the total populace, dividing it by ...

The above calculation does not take into account local businesses who may need /32
just for their application(s). Overall a geo-fixed structure of the Internet
backbone hierarchy looks like the way to go.


--- Iljitsch van Beijnum <iljitsch at muada.com> wrote:

> On 22-mei-2007, at 19:42, Jason Schiller wrote:
> 
> >>> The trouble is, for this to work without too much trouble, address
> >>> space needs to be given out with geography in mind. I don't think
> >>> IANA and the RIRs are going to do that without the IETF telling them
> >>> it's a good idea.
> 
> >> David said it already. The IETF won't waste it's time doing this so
> >> long as it thinks that the proposal will go nowhere in
> >> practice.
> 
> Oh, I'm sorry. I wasn't aware the current practice was entirely  
> without problems and as such, out of the box thinking was neither  
> required nor desired.
> 
> > I concur.  The problem with a geography-related approach to  
> > routing, is
> > that all of the ISP networks also need to be reorganized to also be
> > related to the geography.
> 
> Says who?
> 
> UPS, Fedex, DHL and tons more of these guys all work with the same  
> geographical addressing. They also all use their own ideas about  
> what's the best routing in their own "networks". I got a package from  
> DHL the other day. They sent it from New York to Brussels to The  
> Hague. Most others send it through Amsterdam. They all get to decide  
> all of this for themselves. But the important point is, that the  
> driver in New York doesn't need a street map for The Hague for the  
> package to arrive at my door.
> 
> The problem with all of this is that IETF participants almost always  
> reject the notion of geography-related routing out of hand without  
> really knowing what they're talking about. If I were to tell a second  
> year computer science student that I have a sort algorithm that  
> scales O(n) they'd tell me I'm crazy, too, because how can anything  
> be better than qsort? There are of course reasons why qsort is used  
> all the time and radix sort so rarely that it doesn't even get  
> discussed in the text books, but if pure scalability to ridiculous  
> numbers is what you need, then radix sort fits the bill and qsort  
> doesn't.
> 
> > In short all transit providers will need to restructure their  
> > networks to
> > mirror the geographical regions.
> 
> > All transit providers in a given geographical region would be  
> > required to
> > do SFI-Peering,
> 
> What's SFI-Peering?
> 
> > It is not clear what the approprate geographical region is-- should  
> > it be
> > per continent? per country? per metro area of a give sized
> > polulation? per area code? per city? per LATA? per zip code  
> > designation?
> > per sub-development? per street? per city block? per building? per  
> > floor?
> 
> > Do you give each geographical region the same amount of IP space?   
> > What if
> > a region consists entirely of desert or ocean? Should it be based on
> > population density?
> 
> Since you ask... Below is the text that explains the algorithm, but  
> it's easier to simply look at http://arneill-py.sacramento.ca.us/ 
> ipv6mh/geov6.txt
> 
>     The geographical aggregation scheme splits the global routing domain
>     into a number of smaller regional ones, where flat routing  
> happens in
>     each region. Ideally, outside the region only aggregates are  
> visible.
>     For simplicity and to allow efficient implementation, the framework
>     presented here requires "areas" where flat routing takes place to
>     have a fixed size: a /32 holding up to 65536 (2^16) fixed sized
>     end-user /48 assignments. The maximum number of these /32 areas is
>     also 65536. Areas are grouped in CIDR-like fashion if a geographic
>     region has a population that warrants allocating more than a  
> single /
>     32. The highest level of aggregation is the subcontinent or "zone"
>     level. There are 13 entities at this level, in order of population:
> 
>     1.   China
> 
>     2.   Continental Asia
> 
>     3.   India
> 
>     4.   Northern Africa
> 
>     5.   Asian Islands
> 
>     6.   Western Europe
> 
>     7.   North America
> 
>     8.   South America
> 
>     9.   Eastern Europe
> 
>     10.  Middle East
> 
>     11.  Southern Africa
> 
>     12.  Central America
> 
>     13.  Oceania
> 
>     The next level is the country level. Every country is assigned a
>     range of /32 blocks, depending on population. Countries that are
>     medium-sized or larger may be subdivided according to existing
>     administrative boundaries, such as by state or province. The
>     allocation size per state or province must match the population
>     relative to the country and other states or provinces. The lowest
>     level of aggregation is the metropolitan level. Cities of sufficient
>     size are allocated one or more "metro areas". Assignments to
>     end-users in, or very close to, a city are drawn from one of the
>     metro area /32s allocated to the city. Addresses for end-users in
>     small cities or rural areas are drawn from one of the /32 areas
>     allocated to the country (if not subdivided), state or province (a
>     country/state/province or "CSP" area).
> 
> 8.1 Allocation policy
> 
>     The goals of the allocation policy are:
> 
>     1.  Be completely neutral, fair and unbiased, in order to minimize
>         the potential for political complications
> 
>     2.  Good aggregation at all levels
> 
>     3.  Reasonable flexibility
> 
>     4.  Ease of implementation
> 
> 
> 8.2 Country Allocations
> 
>     Each independent country is allocated at least one /32 area. The
>     allocation size depends on the country's population figure for the
>     year 2001. This is divided by the number D1, which equals 131072.  
> The
>     result of the division is rounded up to the next power of two.
> 
>     This is the number of /32s constituting the country's allocation.
> 
> 8.3 Zone Allocations
> 
>     The subdivision of the globe in 13 zones is relatively arbitrary.
>     However, this division fits current and expected future Regional
>     Internet Regions well, and limits the population per zone somewhat
>     over a strict by-continent subdivision. Zone allocations are chosen
>     such that they are large enough to hold the country allocations for
>     all countries located within the geographic bounds of the zone. If
>     for any of the zones that encompass more than a single country, the
>     number of /32s not allocated to countries is less than 25%, the zone
>     allocation size is doubled.
> 
> 8.4 Subdivision of Large Countries
> 
>     When a country has an allocation of 32 or more /32s, this address
>     space may be distributed over the country by allocating blocks of /
>     32s to existing sub-entities such as provinces or states. The exact
>     geographic bounds of these sub-entities must be clear to the general
>     public and not subject to any controversy. The size of each
>     allocation is determined by dividing the population of the sub- 
> entity
>     by the number D2, which is twice D1.
> 
>     At least 40% of the country allocation must remain unallocated. If
>     necessary, a higher value than D2 may be used as a divisor in this
>     country to reach this objective. The average number of /32 areas per
>     state or province must be at least 4.
> 
> 8.5 Metro Allocations
> 
>     All cities with a population of at least D2 within the city limits
>     are allocated a block of /32s. The population for small cities or
>     municipalities that do not qualify for an address block of their own
>     is added to the closest city that qualifies, if there is one within
>     40 kilometers. (Distance measured center to center.) The size of the
>     address block for a city and its surroundings is determined by  
> taking
>     the total populace, dividing it by D2 and rounding down to the next
>     power of two.
> 
> 
> 



       
____________________________________________________________________________________Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433