BCP for multisite multihoming

[Iljitsch van Beijnum]

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.