Communities

Tue Oct 16 11:28:41 UTC 2001

* iljitsch at muada.com (Iljitsch van Beijnum) [Tue 16 Oct 2001, 12:11 CEST]:
>>> I've been thinking about other information that could be conveyed in
>>> communities. For instance, bandwidth, delay and packet loss.

> On Tue, 16 Oct 2001, Niels Bakker wrote:
>> And generate a route flap every time a link gets used more or less?
>> That would be suboptimal to say the least (the word `countereffective'
>> seems more applicable to me).
> Using dynamic data for this is not going to work in BGP, so this would
> have to be static information (hm, packet loss is not too static,
> hopefully).

Indeed.

> Static system-derived or configured information would already help a lot.
> You can then easily select the route with the highest potential bandwidth
> or the lowest speed-of-light delay, without the need to know a lot about
> the internals of a transit network.
> 
> Introducing "metrics" like this like this is not contrary to BGP design
> philosophy: the way in which an AS selects the best route is not defined
> in the RFC and the length of the AS path is certainly not the best
> possible criterion.

Setting communities based on a prefix's entry point into an ASN is
doable with today's technologies (slight understatement).  What's needed
besides a standard numbering scheme for those communities is a way in
all routers to route packets not merely destination-based but also based
on a community set by the customer advertising the prefix to its
upstream provider.

As already noted, currently communities are mostly used to control
advertisements of one's announcements by upstream providers, and not
for outbound routing, which 

Example:

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. :-)

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
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.

Regards,

	-- Niels.