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

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

On Wed, 26 Jun 2002, Sean Doran wrote:

| In fact you made me think of one possible unexpected consequence. If we allow
| diffserv code points to influence multihoming policy, it would be possible for
| someone who thought they were setting QOS policy to accidentally influence
| multihoming policy. That's not a very welcome side effect, but it may be
| inevitable.

I don't think this will be much of a problem in practice. If traffic
reaching the "multihomer/load balancer" doesn't have a code point yet, the
multihomer will have to set in order to achieve load balancing. For
instance, if there is an OC3 low delay circuit and an OC12 high delay
circuit, it may set the a code point that has the effect the OC3 circuit
is selected for 20% of all packets, and another code point that has the
effect the OC12 circuit is selected for the remaining 80% of all packets.

If a packet already has a diffserv code point asking for a certain phb,
the multihomer can do two things:

1. grant the request and forward and leave the code point alone (or
   translate it into another to achieve the desired effect)
2. refuse the request and overwrite the code point

Always doing 1 frustrates load balancing, and always doing 2 frustrates
the application. Some adaptability is needed here.

For instance, if 10% of the traffic asks for a "low delay" service, the
multihomer/load balancer will simply select the OC3 code point for 11% of
the remaining traffic, so 20% of the traffic (10% by request, 10% randomly
selected to balance the load) goes over the OC3 and the rest over the OC12
circuit.

And what happens when the OC3 line goes down? Simple: the device that
previously forwarded packets over either the OC3 or OC12 circuit should be
smart enough to not forward data over a broken circuit, so now all traffic
flows over the OC12 circuit, disregarding the traffic classification
efforts of both the source and the multihoming/load balancing device.

> How should this be reflected within the multi6 reqs document (if at all)?

Is there anything to be required?

I earn part of my living by telling people how to multihome. They are
willing to part with a decent sum of money for this advice. The same isn't
true for differentiated services: end users don't care. So I don't think
diffserv problems should be show stopper for multihoming. And anything
that isn't a show stopper shouldn't be in a requirements document. (Sure,
we can make it a "nice to have" document...)

> Should one do anything about the doors separating IPv6-global-unicast-format
> from extensions of various flavours, including encoding destination information
> in places other than strictly the destination address?

Do we really want NAT in v6?

>                 source
>                   |
> 		  .
> 		  .
> 		  |
>                 upstream
>                 /     \
>        transit-l       transit-r
>                 \     /
>                  dest.

Isn't this a bit oversimplified? This assumes there is a single place
where all decisions can be taken. If this is true, then we haven't
achieved full multihoming (there is still a single point of failure.) In
reality, things will look more like:

       Source
       /    \
      A      B
     / \    / \
    C   D--E   F
     \ /    \ /
      G      H
       \    /
     Destination

Since selecting the link over AS H to the destination rather than the link
over AS G means (potentially) influencing the routing decisions made in A,
B, and E (and of course the source), this goes directly against the
current distance path routing and hop-by-hop forwarding paradigms.
However, IDPR should be able to handle this quite nicely.