(multi6) more control / load balancing of ingress traffic.

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

Tony,

> Tony Hain wrote:
> Maybe the problem is the assumption that a single approach
> can be found for very different functional requirements.

I don't think it is the case anymore. It seems to me that there
is now a consensus that no single solution is going to address
the problem (finally..)


>> Michel Py wrote:
>> 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.
> Tony Hain wrote:
> Some people want exactly what they have today

These people are dreamers. The routing goop otherwise called BFM for
Big F.. Mess is exactly what we don't want. If we did, there will no
purpose for this WG. I encourage people that want what we have today
to read the following text from the WG charter:
" Specifically, the WG will prefer multi-homing solutions that tend to
minimise adverse impacts on the end-to-end routing system and limit the
number of prefixes that need to be advertised in the Default-Free Zone
(DFZ)."
So let's nail that issue one time for good and say that people that want
to keep what we have today have no place here. The main reason I have
been pushing the requirements forward is that we avoid the market
deciding to implement the v4 solution in v6 (hence the collective
responsibility we have to provide a solution before it is too late).


> Tony Hain wrote:
> I get the impression from comments on the list that there are
different
> opinions on what the goal is. Some people want exactly what they have
> today, some people want a network / centrally managed approach, some
> people want a host / distributed approach, and others want a mix of
the
> above. The current requirements draft tries to give each group what
they
> want, even though the totally network centric and the totally host
> centric approaches are mutually exclusive.

Actually, this is a sound process, IMHO. The requirement draft should be
flexible enough (some would say vague...) to allow different solutions
to
be developed. The choice between solutions is the next phase.

> Until we have agreement on
> what we want for an IPv6 solution, no progress will be made.

I am not sure about that. There needs to be a requirements document,
but the other side of that coin is that no progress will actually
be made until we begin to work on SOLUTIONS.


>> Michel Py wrote:
>> - 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.
> Tony Hain wrote:
> Are you proposing to tie the DNS response to a system which keeps
> track of probable paths from the current requestor and current
> load distribution policy so the source can only pick the
> destination address you want???

Absolutely not (I am sure some people are, though). DNS has absolutely
nothing to do with my proposal.

> In any case routing is part of the key,

I agree with that. My proposal is based on BGP.

> and destination address only plays a role for those parts of the
> infrastructure that route on that rather than a default. If a source
> site defaults to a particular ISP which the destination is also
> connected to, there is nothing in the destination address selection
> that will change the way traffic flows.

This is a very small part of traffic, and the only one that we don't
have to bother with. Same ISP to same ISP traffic is a non issue.

> I happen to be one of the people that believes that host address
> selection is part of the answer to the long term problem.

I know that, and so do I.

> That does not mean that a destination site can micro-manage its
> incoming load balancing though, unless there is a connection to
> the DNS response which limits the sources choices to current load
> balancing policy and the concept of a default route is completely
> removed from the system.

No. I think you have missed part of my previous posting.
Let's try again:
A site has three different PA addresses from three different transit
providers. The selection of the destination address among these three
DOES INDEED change the way the traffic flows, because each different
PA address will flow to a different provider and finally reach the
destination site by a different circuit and interface.

The source, obviously, makes the choice of the destination address.
If the destination hints the source on the choice of one of its own
PA addresses, it can indeed micro-manage its own ingress. I believe
you could call that route injection, to some extent.

RTFD (1)
http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt

> While it is possible for policy to say select from any available
> address, most implementations will default to longest matching
> between available source and available destination addresses

That is why my draft calls for a fixed size of /48 for all
multihomed prefixes. AAMOF, I suggested privately to you to
incorporate that in your own draft.

> Because that approach is most likely to take the shortest path
> through the infrastructure. In any case once the packet leaves
> the host it is the routing system that determines the packet path,
> not address selection.

Correct, address selection has influenced the path BEFORE it leaves
the host by specifying which of the multiple providers to use at
the destination.

> If a site multi-homes for resiliency, host based address selection
> approaches are appropriate, while if a site multi-homes with the
> intent of micro-managed load balancing, those are inappropriate and
> route injection mechanisms make more sense

Definitely. MHTP can be indeed be considered a route injection
mechanism as well as a NAT one.

I don't see why address selection and route injection are
incompatible, though. I think they are complementary.

> but I still maintain that a destination has
> limited control over the absolute path).

For sure, it can't control the traffic going out a default route,
and it can't control the path among transit providers unrelated to
either the source or the destination, but it can have control of
which one, among all its own providers, is going to receive the
traffic; again this is micro-managing the inbound traffic, which
where it needs to be managed since there is nothing to do about
the vast majority of hosts that will stay single homed with a
default route outside.

Michel.

(1) Read This Fine Draft