|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Communities
> Date: Tue, 16 Oct 2001 18:30:05 +0200 > From: Niels Bakker <[email protected]> > > 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. > this (12.0T and onwards) with different VRFs. I've seen companies who > have something like that in production; packets hit the same router a > few times in a row in a traceroute. Interesting. I was unaware of this. > >> 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. me <--> you <--> 701 me <--> you <--> 1239 Both are valid. > > 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. > 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. Not providing fine-grained tuning accomplishes nothing positive, and can be a negative thing. Offering it provides benefit, and is not difficult.[2] [1] Reminder: Hypothetical example. Interpret accordingly. I used 701 and 1239 in my original example, and don't care to change the scenario. [2] Yes, more maintenance with communities. But a few dozen is all it takes to handle many ASen with a few different lengths... both the initial effort and upkeep are negligible. Search the archives for this discussion. 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 <[email protected]> To: [email protected] 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 <[email protected]>, or you are likely to be blocked.
|