* eddy+public+spam@noc.everquick.net (E.B. Dreger) [Tue 16 Oct 2001, 21:09 CEST]:
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. Zebra doesn't actually forward packets. Ciscos with newer IOS can do Correct. It edits the *ix kernel's FIB, adding and deleting routes. However, Zebra running on a single machine can have multiple BGP processes running... which is along the same lines.
Except that Zebra currently does not have any provisions to be able to tell the forwarding engine it's running on (i.e. any Unix) a rule to the effect of "If packets originate from this peer [this interface] and are destined for this prefix, route them over that particular interface instead of the interface that would've been taken for all packets from all other prefixes." Which is, in effect, what multiple FIBs mean in practice.
Frankly, if I were B 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. Yes, I would complain if you sent me packets with source addresses you shouldn't be sourcing (i.e., not your own). Traffic from 701 or 1239 should not pass you to reach me (if I were B and you customer A). Whoa! Where did I say spoofed packets? If 701 is one of your upstreams or peers, then I can exchange traffic with 701 all day long. I never indicated using improper source addresses. Please reread my post.
Sorry, I misread you. Let me restate my previous statement before that a bit then: Yes, I would mind them attempting to choose which exit point into AS701 their packets would take. This could lead to suboptimal performance for all B's customers and a loss of control over the bills sent to B by its upstream providers. In addition to having to monitor its own network for long-term bottlenecks B will have to stay on a continuous alert for customers clogging one link.
me <--> you <--> 701 me <--> you <--> 1239
Both are valid.
Used above by me, customer A <--> B <--> AS701 (West Buttmunch) <--> AS701 (East Buttmunch) (numbers hold of course no discernable relationship to reality)
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. This is about packets from the world via me to you, not from you to the outside world. The case you just described already exists; I wrote so before (albeit in a bit broken English). The only routing decision customer A can force upon B is "Send packets destined for these netblocks <here's a BGP announcement> to me," and In your scenario. But this is arbitrary; it is not borne of necessity due to the technology.
Actually, yes. The technology exists today for customer A to tell B to announce A's prefixes only to some peers/upstream providers of B, but not to route packets from A all via some peers/upstream providers of B and not via the others, even though B would choose those routes for its own packets (and thus has installed them into the FIBs of their routers).
enforces this via a contract both parties enter in and A (presumably) pays B for. Let's say that I'm strictly a Web host. Inbound traffic is negligible. I send any and all 701-bound traffic via you; any and all other traffic goes through <some other upstreams>. No complaint there -- and I can do this in your aforementioned scheme.
Why do you balk at a community that says "I dislike 1239"[1], thus _preferring_ 701, when I could simply route _all_ non-701 traffic over another one of my upstreams? IMHO, your dislike of tuning is illogical... I can sway the balance _far_ more with coarse-grained routing when you don't provide fine-grained controls.
Because then you introduce C into the mix, another upstream provider of A. That's cheating. :-) I thought the whole discussion was about B having multiple exit points and A influencing what exit points from B's network A's packets would take?
Not providing fine-grained tuning accomplishes nothing positive,
Simplicity for its own sake also has value (even aside from benefits like easier troubleshooting in case of failures, no need to generate transient outages while fiddling with the tuning knobs, etc.). Regards, -- Niels.