North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Request for Comments on a topological address block for N. Calif.
> From: firstname.lastname@example.org (Andrew Partan) > Lets assume that everyone on the Boston area has a geographic address > and that AlterNet and some other ISP (SmallGuy) have some customers in > this area, and that AlterNet and SmallGuy peer at some Boston area > exchange point. ... Now if I peer with some other ISP in some other area > (say someone in San Francisco) ... I have now suddenly offered transit for > SmallGuy between San Francisco and Boston. >Well, there is a "fix", but this whole topic of traffic is a major can of >worms. There's two kinds of traffic that Alternet can provide to SmallGuy: a) non-transit peering, meaning Alternet announces only routes it originates to SmallGuy (and vice-versa, though that's for SmallGuy to ensure!) and takes SmallGuy's route announcements and floods them through Alternet's ASes (but no others!), or b) transit peering, meaning Alternet announces to SmallGuy all routes that SmallGuy is paying to get (Alternet's plus everyone else's presumably, though transit-to-some-but-not-al ASes can also be done, and where Alternet propagates all of SmallGuys route announcements to the ASes SmallGuy buys access to. [Buying access to some ASes but not the whole Internet as seen by Alternet can be hard since some of these ASes may not be directly connected to Alternet, in which case SmallGuy must also pay for transit to the ASes between Alternet and the ones he desires. In practice SmallGuy will buy transit to the whole Internet as heard of by Alternet.] [Non-transit peering between Sprint and Alternet means that Alternet and Sprint announce their own routes plus their transit customers' to each other. This is so because in effect, Alternet's routes to its transit customers can be considered to be Alternet's for the sake of the definition I gave above in (a).] This should make the can of worms vanish. >(This, of course, does lead to asmmetric routes. [...] Assymetric routes can be avoided. >One fix to do this is for a provider not to accept traffic from another >provider unless that traffic is destined to an "appropriate" customer (exact >definition varies) of the first provider (or a customer of a peer provider of >the first provider, one which has a transit agreement with the first >provider). [I'll assume permission to use the following names for the scenario below: Alternet, Sprint, MCI, SmallGuy. May I? :) Any resemblance to reality is pure coincidence. :)] If Alternet and Sprint have a non-transit peering agreement, then Alternet announces all of its routes, including those of its transit customers, to Sprint and vice-versa. Now if MCI also peers with Sprint and Alternet and f everyone sticks to the definition of transit and non-transit peering (i.e. MCI, Alternet and Sprint configure their routers appropriately) then there's no way that Sprint will transit SmallGuy's traffic to MCI, because MCI won't hear any routes to SmallGuy through Sprint and Alternet will only hear MCI's routes where it peers with MCI (if Alternet heard MCI routes elsewhere, such as through Sprint due to a configuration error, it would still use the route through MCI as it would have a shorter AS-path). There is then no route assymetry in this system. In practice this means that everyone has to be careful to filter *outbound* announcements so that peers hear only what they are meant to hear. So Alternet will have outbound filters that allow only routes it originates plus routes originated by its transit customers to make it to Sprint, and vice-versa. Also, in practice, a new provider that is trying to get access to the whole net will have to arrange to buy transit through someone else until it has enough peering arrangements in place with other providers that it can offer decent reachability to its transit customers. Large providers like Sprint and Alternet end up using large configurations to put this sort of routing policy together. >The definition of "appropriate" is tricky; does this mean any customer (which >still leaves you vulnerable to "dumping" of long-haul load to customers of the >dumpee), or just "local" customers? If the latter, would you rather the >customer not get the traffic at all (if the traffic source is attached to a >provider which doesn't have an attachment to the destination's provider, near >the destination - we'll call this source's provider a minimal-connect >provider)? If not, how do you prevent "dumping"? By carefully controlling outbound announcements, see above. It's true that a bad player can rig the system so that a non-transit peer will transit one side of the traffic to some other destination (e.g. MCI could put static routes in its routers for SmallGuy pointing to Sprint; Sprint will pick up traffic for SmallGuy from MCI because Sprint has a route to SmallGuy, but traffic between SmallGuy and MCI cannot go through Sprint without Alternet's help). In practice noone cheats like this. >In geographic addressing this means that you don't accept traffic for another >metro from a provider unless you have a peering arrangement with them, >otherwise you wind up doing the long-haul. This stops "dumping", true, but >still leaves your customer not getting traffic from minimal-connect customer. >You can do more or less the same thing in connecvity-based addressing, and you >have the same cut-off-minimal-connect-guys/allow-long-haul-dumping choice... If geographic addresses don't match the underlying topology, then dumping is hard to prevent without fragmenting the net or allowing CIDR holes or dropping aggregation, which is to say abandon geographically assigned addresses. > If SmallGuy is not paying me for transit, then I am not going to do > this. >Ah, there's the rub! What you really want, it seems, is traffic settlements >(since I don't think we can adopt/enforce a simplistic you-always-carry-your- >customers-traffic-pretty-much-to-the-destination model, which would get rid of >any need for settlements) but right now the Internet doesn't have them, for a >whole host of good reasons. Finely detailed traffic summaries cannot be kept on the net the way telephone calls made can be logged by phone companies, at least not right now. If detailed summaries are ever introduced, the logging will be done at the interface between carriers and their customers, not at exchange points (IMHO), and the summaries will be in the form of packets transited to a certain AS. Or will the sort of router used at exchange points ever have enough oomph to do this sort of traffic logging (source AS, destination AS, packet count). >There's an interesting analogy here between traffic settlements and routing >setllements; the Internet will work fine with no administrative overhead if >everyone is reasonable. However, if people try and take advantage of the >system, to a point where administrative controls are needed, the overhead >of those controls will be substanial, to the point where the cure might be >as bad as the disease. Hmm.... Sure, but if some players collude to have others transit what they shouldn't and this is discovered, then it's all over for the rogue players. You see, even without a central authority it is possible to have some justice in the system. > Noel > Nick