Communities

Tue Oct 16 16:09:04 UTC 2001

> Date: Tue, 16 Oct 2001 13:28:41 +0200
> From: Niels Bakker <niels=nanog at 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 at brics.com>
To: blacklist at 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 at brics.com>, or you are likely to be blocked.