(multi6) control / load balancing of ingress traffic.

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

Masataka and Tony,

> Masataka Ohta wrote:
> Assume that a site is connected to ISP A and B.
> If the site negotiate with ISP A and B individually, egress routing
> is fully controlled by the site.

Not necessarily, see below. Or maybe, this might be true as of today
but the multihoming solution we want for IPv6 is not what we have
today for v4.

> Otherwise, ISP A and B must cooperate for the welfare of the site
> even if they are hostile competiters.

Not necessarily either, see below.

>>>> Tony Hain wrote:
>>>> The other point is that for inbound load balancing, the receiving
site
>>>> only has control as long as it does not conflict with origin site
>>>> policy, or the topology is deep enough that an intermediary
abstracts
>>>> out the differences.
>>> Masataka Ohta wrote:
>>> Again, I agree with you.
>> Michel Py wrote:
>> I disagree with both of you here as well. The receiving site does not
>> have much control over the traffic it receives, but let's not forget
>> that a solution includes BOTH the sender and the receiver, which
means
>> that indeed inbound load balancing can be controlled, not by the
receiver
>> but by the sender.

> Tony Hain wrote:
> This makes no sense.

See below if it does.

> Masataka Ohta wrote:
> Are you saying "EITHER"?

Yes, see just below.

Let me try to explain this.
- Site S is multihomed to providers A,B and C.
- Site S has received aggregatable PA addresses from all three
providers.
- The multihoming solution is a multi-address one, which means that each
host on site S has several addresses, one for each provider and possibly
a PI address as well.
- In the cloud, during the transport of the packet, one of the PA
addresses
is going to be used. This effectively assures load balancing among the
different providers by the choice of the destination address by the
source.
- So, the provider used at the destination is controlled by the source
when
the multihoming protocol chooses among the different possible
destinations.
- If that multihoming protocol bases its decisions on info provided by
the
destination, you can truly says that the destination controls its own
ingress traffic. DESTINATION ADDRESS SELECTION is the key here, not
routing.

So, the ingress traffic to a given site can be controlled by the source,
or by the destination site itself if if the multihoming protocol feeds
the source with the correct info, or by both.

Note that my model calls for selection of the path by the destination,
in most cases, which is, indeed, load balancing for ingress traffic.

Tony, this is not a routing decision but a destination address
selection decision.

> Tony Hain wrote:
> I am sorry, but there is no way I am going to allow a destination site
to
> dictate that I send my traffic over my highest cost path.

I am sorry to say it, but there is nothing you can do about that. If
the host or router on your site picks a PA address that goes over
your highest cost path, though.

> It is unfortunate that BGP has fostered the complete fantasy that a
site
> can control the traffic towards itself. The holder of the packet is
always
> in control of where it gets sent, and that is true for each hop along
the
> path.

As of today, it is a fantasy because hosts have only one address. In a
multi-address multihoming scenario, this becomes true. Christian,
correct
me if I'm wrong, but your draft is all about host selection among
multiple
possible choices.
Like it or not, part of the multihoming solution is a multiple PA
address
without a PI that this company in Redmond, WA and some other people are
working on.

Bottom line is: multiple-address solutions do not give a hoot to
routing.
I don't like the idea because of the added complexity, but multi-address
solutions are, IMHO, unavoidable especially dealing with the kind of
scalability that multihomes cable and DSL personal setups.

The point I am trying to make here is that we collectively need to
unlearn
the fact that a host has only one address that does not change.


> Masataka Ohta wrote:
> "very" is not a proper wording to discuss scalability.
> "very scalable" = "poorly scalable"

My english is not very scalable, I'm afraid :-)

>> Gentlemen,
> I'm not. I'm not a lady, either. :-)

Hehe. Looks like me. I am fully reassured, now.

Michel.