[43503] in North American Network Operators' Group
Re: Communities
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Tue Oct 16 09:07:23 2001
Date: Tue, 16 Oct 2001 15:07:02 +0200 (CEST)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Niels Bakker <niels=nanog@bakker.net>
Cc: <nanog@merit.edu>
In-Reply-To: <20011016132840.O87747@trance.org>
Message-ID: <20011016144541.V44054-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
On Tue, 16 Oct 2001, Niels Bakker wrote:
> As already noted, currently communities are mostly used to control
> advertisements of one's announcements by upstream providers, and not
> for outbound routing,
I'm sure it's used more for the former than the latter, however, there are
networks that look at communities for outbound routing. A little more than
I expected, even. This seems to happen mostly at multihomed networks. For
instance we (AS12854) set a lower metric for routes that come in over a
certain exchange point and a lower local preference for routes learned
somewhere across the atlantic.
> 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.)
Well, lines used to be both expensive and slow, so at least there is
progress...
> 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.
Yes, this is always the problem with BGP. If I like low delay, but my
upstream prefers a high bandwidth route that is also available for that
destination, I don't get to see that nice low delay route I would have
liked to use.
> 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. :-)
B could also do away with layer 3 and sell layer 2 (or layer 1)
connectivity to C, where each customer can select the appropriate quality
levels. Other options are for B to focus on one selling point and try to
optimize the network for that selling point, or use their expertise to
find the perfect middle ground, or run several parallel networks.
