RE: Multihoming by IP Layer Address Rewriting (MILAR)

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

Iljitsch,

I completely agree with the following:

Iljitsch van Beijnum wrote:
>>
>> - the transport layer is not the best place to implement
>> multihoming: the natural place is layer 3 and implementing
>> it there also avoids large amounts of API problems and
>> higher layer changes
>>
>>- multihoming should work in all stages of a connection,
>> including setup
>>
>> - tunnels are a Bad Thing: they waste bandwidth, hide
>> the network topology and current PMTU discovery standards
>> and implementations easily break in the presence of careless
>> tunnel deployment
>>
>> - a router implementation is good: no need to change large
>> numbers of hosts


I would tend to say "visible over TWO or more transit networks"
for the following but agree on the rest.

>> In the presence of a good multiple-addresses multihoming
>> scheme, the requirement for getting an address block could
>> be being globally visible over three or more transit networks.
>> I would be very surprised if the number of networks that
>> qualify under these conditions is more than a few
>> thousand world wide.


I am a little more reserved about this:

>> - using multiple address ranges is the only way disconnect
>> the growth in multihoming from the growth of the global
>> routing table

Until someone finds a mechanism that can do it. Besides, the
growth of the multihoming table, if it contain multihoming
prefixes only and not the result of poor summarizations could
be controllable as you mentionned above.


>> Before I write up a draft, let me run it by the list.
Please take the time to have a look at:

http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt
<http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt> 

(I'd rather have the list look at this unpublished version
opposed to the published -00).

Thanks
Michel