asymmetric routing

[Ville]

Michel,

On Mon, 28 Jan 2002, Michel Py wrote:

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

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. Perhaps the specific IP-address used belongs
	to PPBW2 simply because they provide better service in cases of
	failure and offer stability (whereas FLAT1 could be changed into
	another flat-rate provider FLAT2 with no change visible to the
	end-user as their addresses are not used for anything).

        Any reason to tell a paying customer you are not willing to let
	his elsewhere-belonging packets travel back through your network
	just because s/he prefers static routing? Talking in the gigabit-
	range, yet about sites that do not qualify for (or desire) a
	direct PI-allocation. Carriers can hardly be expected to babysit
	players of size as they will only move elsewhere if mistreated.

        Another example: User wants to preserve his old pay-per-bandwidth
        IP-address 2001:PPBW2:cust::1 which is a bandwidth-exploder service
        (say, anonymous FTP). He downgrades this specific PPBW2-pipe
	from GigE into the 2 Mbit class while upgrades his connection to
	FLAT1 into 10GigE.

        Problem solved: He pushes everything back [in direct contradiction
        with the proposal and unicast-rpf] via FLAT1, which boasts lots of
	unoccupied b/w and does not charge by the byte. 2 Mbit is well
	enough for the incoming "PASS ftp@", "PASV" and "LIST" via PPBW2,
	while all true data is pushed back through the flat-rate 10GigE
	provided by FLAT1.

	Not really commenting on neither the current state of things nor
	the future I either envision or fear. I am rather trying to build
	a sample of what I would view as some of the schemes expectable.



> Michel.

Cheers,
-- 
	Ville <viha@stealth.net>  Network Security/IPv6 Solutions
				  Stealth Communications, Inc.