Date: Tue, 16 Oct 2001 13:28:41 +0200 From: Niels Bakker <niels=nanog@bakker.net>
(Too lazy^H^H^H^Hrushed to rewrap quoted lines <= 72 char) [ snip ]
Customer A has a connection to upstream B and speaks BGP with B. B as two different paths to C: one cheap and slow, one fast and expensive. (This seems to be a business opportunity - devise lines that are both cheap and fast.)
Now B can set communities on routes received from C based on where a certain prefix was received. If they overlap, however, only the best route out of the two will be passed on to customer A. If this obstacle is overcome, A still faces the problem of getting B to discern between packets meant for either exit point to C. B could reengineer its network to basically exist of two separate entities (a cheap one and an expensive one) and let customers like A to connect to both, or extend all its routers to have a pre-prefix source+destination routing table entry to decide where to send packets.
This seems to need quite some engineering work. :-)
I've thought about this before. Let's say that I have a DS3 to 701 and a 4xDS1 to 7018. I might sell a DS1 to NetX, and advert their routes[1] to both upstreams. If I sell a 15Mbps frac-DS3 to NetZ, I'd better use my 7018 connection for backup only on their routes. In short, we start looking at multiple FIBs. It's not really that much more difficult; it's more of a scalability issue. I know that Zebra can run multiple router processes, but I've not played with this feature... perhaps that's a start. Or, if you want to get ugly, you could have your upstreams speak multihop EBGP selectively with your downstreams. *ducking and running* [1] Ignore issue of table fragmentation for now. That's another thread...
Or A could buy B and do it themselves.
On a side note, A's possibilities of influencing inbound routing decisions - given that B acts on communities set by A, like `Prepend own ASN a few times before sending over just this link' or `Don't announce to D at all' - are already technically possible. Frankly, if I were B
Correct. And a few upstreams allow this.
I'm not sure I'd be all that happy with customers influencing my routing decision process. They hand me their packets (or not); that should be it.
I disagree. Let's say that you sell me transit, and purchase yours from 701 and 1239. Would you complain if I fill my pipe to you with traffic to/from 701? No. If I fill it with traffic to/from 1329? No. Why, then, would you complain if I set a community to _prefer_ 701 over 1239 or vice-versa? By giving your downstreams fine- grained tuning, you allow them to tinker for a system that they like... and you don't reach the extreme cases that are possible even without fine-grained tuning. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.