RE: Multihoming by IP Layer Address Rewriting (MILAR)

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

Iljitsch,

Thanks for your comments.


Iljitsch van Beijnum wrote:
>>>> Until someone finds a mechanism that can do it.
>> Ok, you're right, other ways, such as on-demand created routes, are
>> possible, but I don't see it happening.

Me neither, that's why I designed MHTP.


>> I'm not as pessimistic as some others: I think the current
multihoming
>> practices could continue to work for the foreseeable future if BGP
>> implementations can be optimized.

So do I, and this is how I consider MHTP: an optimization of the
existing
model, a waiting solution, and something that would provide a working
base for two things that are likely to be used anyway:
- A prefix reserved for multihomed addresses.
- The concept of multiple addresses per host.


>> Still, if we can create a good host-based multihoming solution, this
will
>> drain away much of the growth of current multihoming practices,
giving us
>> all more breathing room. Also, it makes multihoming reachable for
>> everyone. With IPv6 we're in the unique position that the
implementations
>> are still very fluid, so we should take advantage of that.

Yes, but I still have to see that solution. Again, MHTP does not pretend
to be "THE" multihoming solution.


>> However, your proposal depends on changing the Internet core routing,

I do not agree with that. The core of the routing would still be
the existing, strongly summarized BGP4+ DFZ that we want to keep.
What I propose to change in not HOW the traffic is routed but WHAT is
being routed (because it has been translated).


>> The main advantage of your proposal is that you solve the
"alternative
>> address discovery" problem.

By using the same, proven mechanism that works today: a BGP routing
table.


>> Note that a network that is part of the DFZ does not have "an ISP".

An interesting semantics issue. To me, an ISP is who provides
connectivity
to the Internet. In the US, it is fairly common to buy a DS3 or bigger
pipe with full BGP feed from one or more ISP(s) (that would be for
companies
that have an ASN and a CIDR block).

>> you pay an ISP to route traffic to all destinations connected to the
Net

I don't think so. I pay my ISP to provide me a connection to the
backbone
without the hassle of getting into a colo where I do not want to move
and
without the hassle of being part of an exchange which is not my core
business.


>> in other words: you pay for a default.
No, I'm getting a full BGP feed.


>> In the default-free zone there are no defaults

Let's say there SHOULD be no defaults, related to the fact that
10.0.0.0/8 SHOULD NOT been advertised in the DFZ either....


>> (but the reverse is not always true: a network running without a
>> default is not necessarily part of the DFZ)

Agree. A network is part of the DFZ because it has its own block, the
same
animal that clogs the DFZ's routing table.


>> So using the DNS seemed like logical choice.

There are way too many people that consider a DNS-based solution an
absolute
no-no to attempt any DNS solution, IMHO.


>> Any consensus on BGP changes is a long way off

Definitely. I guess I have not made myself clear about the relation
between
MHTP and BGP. What should I change in 6.2.9 of
http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt ?


>> Maybe we should come up with some more specific requirements for
multiple
>> addresses / address rewriting solutions. Or we can just wait and see
who
>> is the first to produce code.  :-)

This might no be the fastest course of action. What if the people that
write
the code are waiting for us to decide something ;-)

Michel