Re: draft-ietf-multi6-multihoming-requirements-03

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 2 Jul 2002, Joe Abley wrote:

> > > As I said, I think that presupposes a solution.

> > I didn't have one in mind when I wrote it.

> I was talking about the solution which involves "policy-based
> routing and forwarding mechanisms". Seems to me that the requirement
> in the document right now could be met without using those.

Ah, I see. I was thinking about:

1. Both ends have the special applications use different addresses that
   are routed over just one connection (probably better to use PA space
   for this rather than a more specific in BGP)

2. Policy routing based on application characteristics such as IP address
   or protocol/port number

3. Diffserv code point that has the effect a specific connection is
   selected

Are there additional ways to accomplish this?

> For example, suppose the pure aggregation/no hole-punching addressing
> and route advertisement scheme is strictly adhered to, and the effect
> of multi-homing is to number each interface with an address from each
> transit provider. Further suppose that the TCP endpoint address
> selection algorithm can be influenced by some hierarchical policy
> signalling mechanism. In that case, inbound traffic towards a TCP
> endpoint could be moved between transit providers without resorting
> to CIDR abuse.

You still need either:

- BOTH ends to have their IP address for this application in a separate
  range, or

- use policy routing based on address or protocol/port to select the right
  exit connection

The former is workable for things like NNTP, where the traffic flow is
easily predicted and some optimization in IP addressing is well worth it.
The latter is a dirty hack IMO, because it breaks hop-by-hop forwarding.

When we get basic multihoming working for IPv6, there is probably a lot we
can do to optimize load balancing while providing differentiated services
(and/or the other way around).

> More generally, you seem to be saying that the requirement as stated
> reduces to something trivial, which of course should be supported by
> any adequate multihoming architecture. If I have got that right, then
> what's the harm in letting the requirement stand in the document?

There is not much harm. Still, my original point remains: the wording
could lead to confusion about current IPv4 capabilities.

Iljitsch van Beijnum