Noel - Your model is one of the many things that gets solved when doing closest-exit routing with external peers. A quick pair of definitions: a customer is someone paying for transit everywhere through a particular bitpipe; an external peer is a non-customer with which one exchanges traffic. For the most part these days, external peers are not generally also customers. So, in the model I mentioned, we effectively have two customers paying to exchange traffic over A, or over A and S. The fact that one single organization is picking up the bill is not really relevant, or necessarily even knowable. The point is that A is being paid for two customer connections, or A and S are each being paid for one customer connection. A and S are external peers. In your model: | Two large carriers, P and Q, are | interconnected at multiple sites, among them X and Y. Let's further suppose | carrier P has two customers, C1 and C2, near X and Y respectively. We'll assume that P and Q are external peers with no customer/provider relationship with respect to X and Y. There are several answers to your questions, depending on routing policy of both parties. I won't do all variations, but here are the simple cases: P does closest-exit routing towards Q; Q takes MEDs to do best-exit routing towards prefixes P announces, or Q uses an advisory line to allow P to specify exit points from Q to P on a per-prefix basis. Since we have destination-only routing in place in the Internet, P could dump traffic for C1 on Q at Y, and Q would route it to X, deliver it to P, which would carry it to C1. Trivial. Seen it happen. It works. However, Q cannot do the reverse to P. If Q dumps traffic for C2 onto P at X, P would dump it right back to Q at X. In short, you get a routing-loop. Example 1: c3->P--->PY-QY--->Q------>QX-PX-->C1 Example 2: PX<-QX<---c4 | \->QX | PX<-/ There are ways in which this can be worked around, for example, by using outgoing routing filters to announce certain networks to P only at C1 or at C2, or by using differing AS paths in the announcements and the like. I imagine that anyone caught doing this deliberately and without explicit permission (and in practice it has been pretty easy to catch) would quickly find themselves with no peering at all, and would just as quickly become a pariah. (Non peers at X and Y could aim static routes too, which is equally ugly, and the way around this on the engineering (as opposed to legal department) front, on top of pariah methods and the fact that there is the return-traffic problem that isn't always trivial to deal with, is to break level-2 connectivity between, say, N and Q at X and Y, or to use various ugly war knobs in people's favourite routers.) If Q voluntarily allows P or N to do this type of long-haul routing through Q's backbone (AS healing and the like), then imho Q is pretty stupid, and not just for the reasons you mention. Also for some of the reasons you touch on, I think that having a customer relationship with anyone at X or Y would also be a silly thing for Q to do. Sean.