asymmetric routing

[Michel Py]

Ville,

>> Michel Py wrote:
>> a reason NOT to filter customer's (ACL) by denying everything
>> except the customer's PA prefixes. [...]

> Ville wrote:
> Assume the case of a content-provider (return-traffic business)
> If one, as an end-user, receives transit from two different
> providers (flat-rate FLAT1, pay-per-bandwidth PPBW2) and sub-
> sequently receives two separate prefixes (2001:FLAT1:cust::,
> 2001:PPBW2:cust::), he would probably rather route back any and
> all non-local traffic via FLAT1 unless the circuit in question
> is already overloaded.
> [SNIP]

Technically, a valid scenario. Realistically, not much. I know
lots of people that, placed in the shoes of FLAT1, will deny return
traffic with a source address that belongs to PPBW2. The rationale
is: PPBW2 is my direct competitor. If I have to carry their traffic
I want money for that.

In terms of fault tolerance, this is worse than a single link. If
either link is broken, the content providing is gone. The chances
of having one link broken out of two are twice those of a single
link. It would be better to have the traffic originating to FLAT1
in the first place as the "PASS ftp@", "PASV" and "LIST" will not
change much of the bandwidth situation.

In this situation, the backup link still makes sense for a MX with
higher priority to keep email flowing and still providing access to
the net. However, there is no gain in policing the return traffic
originated to PPBW2 to return over FLAT1. If FLAT1 is down, you are
down anyway.

Michel.