From last week's thread on Cogent service and selective prepends, I've
compiled a list of transit providers that support BGP communities for
selective prepends when propagating routes to peers.
sprint
c&w
gblx.net
level3
Williams Communications Group
internap.com
Is anyone aware of others, preferably of similar size to Sprint and C&W
(and in the US) that support this? I need to choose an additional
provider real soon and already have Sprint and C&W. We'll be connecting
ideally in Orlando, FL, but can take connectivity in most of the bigger
cities in FL.
Not the size of Sprint or C&W but we support it also:
http://www.eli.net/technical/bgprouting_policy.shtml
Regards,
Dave
jlewis@lewis.org wrote:
I'd like to ask a slightly different question. At the providers
who do support this feature, how many of your customers actually
use it?
The last time I asked a couple of people this question in private
the answer was generally a number of customers that could be counted
on one hand, even at some quite large providers.
Date: Mon, 30 Sep 2002 17:09:45 -0400
From: Leo Bicknell
I'd like to ask a slightly different question. At the
providers who do support this feature, how many of your
customers actually use it?
This is a bit like asking "how many of your customers use BGP?"
The last time I asked a couple of people this question in
private the answer was generally a number of customers that
could be counted on one hand, even at some quite large
providers.
It seems most providers don't bother tuning routes unless there's
congestion. i.e., proactive attempts to find lower-latency paths
are rare.
It also seems the people who use selective prepends really like
them. I give stronger recommendations for providers who offer
selective prepends... it appears people generally are oblivious
to its existence, but become intrigued when they learn of it.
Eddy
People like to play with knobs, even when nothing happens. Call it a
routing placebo if you will. 
I'd like to ask a slightly different question. At the providers
who do support this feature, how many of your customers actually
use it?
I can tell you that since this weekend Telia has one more customer using a
selective prepend. I'm glad they offer this feature since there wasn't
really any other way to avoid a congested path.
The last time I asked a couple of people this question in private
the answer was generally a number of customers that could be counted
on one hand, even at some quite large providers.
I think most customers don't know how this works. Maybe someone should
write a book that explains this kind of stuff...
Iljitsch
In a message written on Tue, Oct 01, 2002 at 12:16:07AM +0200, Iljitsch van Beijnum wrote:
I think most customers don't know how this works. Maybe someone should
write a book that explains this kind of stuff...
I'm not so sure I'd come to that conclusion. I think when most
customers see a problem on their transit providers network they
would rather open up a ticket with their transit provider, and have
them solve the problem.
Most people I see using this feature fall into two catagories.
The first type doesn't believe the provider can fix the problem
but is forced to use them (due to price, management, whatever) and
uses this to avoid their NOC because it doesn't work. The second
type of person believes they can actually do a better job of routing
than their upstream. This may even be true in some cases (where
the customer has several transit providers all supporting this
'feature'), however I suspect in many cases the customer is actually
making their own life worse.
In general what this means is rather than having a couple of standard
route-map's/route-policies that get configured once and applied to
all peers you end up with a per-peer specific configuration. It
would seem to me that the opportunity for mistakes is grealy
increased. Even if we assume all the people using it really need
it, is it worth risking the performance of 500 or 1000 customers
for the 5-10 who actually use the features?
In a message written on Tue, Oct 01, 2002 at 12:16:07AM +0200, Iljitsch van Beijnum wrote:
> I think most customers don't know how this works. Maybe someone should
> write a book that explains this kind of stuff...
I'm not so sure I'd come to that conclusion. I think when most
customers see a problem on their transit providers network they
Some NOCs, even ones that support this on their network, don't understand
it...or at least have staff that don't even come close to grasping it. It
wouldn't surprise me at all if it's beyond a great many customers.
Most people I see using this feature fall into two catagories.
The first type doesn't believe the provider can fix the problem
but is forced to use them (due to price, management, whatever) and
uses this to avoid their NOC because it doesn't work. The second
type of person believes they can actually do a better job of routing
than their upstream. This may even be true in some cases (where
the customer has several transit providers all supporting this
'feature'), however I suspect in many cases the customer is actually
making their own life worse.
Consider a network with several transit providers. Each transit pipe is
incapable of handling all that network's traffic. The pipes may even be
of wildly different sizes. Letting BGP decide where traffic goes (or
comes from) with no tuning just won't work. You'd end up with some pipes
overutilized and others underutilized. In this case, selective prepends
make it possible to shift traffic around or decide "we're going to try
forcing all ASxyz traffic to come to us over pipe A."
There's also the occasional case of medium to long term overloaded peering
between large providers in which case you might want to do all you can to
force traffic to/from ASxzy to not come/go via pipe A.
increased. Even if we assume all the people using it really need
it, is it worth risking the performance of 500 or 1000 customers
for the 5-10 who actually use the features?
I wonder if anyone from Sprint or C&W is willing/able to say what
percentage of multihomed customers utilize these communities? With enough
full views from enough route-servers, it might even be possible to analyze
the data and see how many use this.
Are you talking about the customer or the provider?
A provider with a well thought-out community policy shouldn't need per-customer
route-maps. The customer sends the provider the appropriate communities and the
standard customer route-map takes the appropriate actions. That's one of the
major benefits of communities, match on the community not the customer.
I see your point about questioning the cost-benefit; however any provider of
reasonable size needs a community policy anyway, so most of the cost is
unavoidable. If done right it only needs to be incurred once.
A customer, on the other hand, will of course need separate policy per transit
to take advantage of provider-specific TE communities. For the typical
multi-homed customer with a few upstreams this is hardly unmanageable.
Bradley
Just to summarize the private replies I got about this feature.
One network showed moderate use. All of the rest showed very
limited use (count the customers using it on one hand or two). It
was suggested by a few people that only the largest customers tend
to use it, which may weigh in the decision to deploy it. Several
people mailed me to say they were resisting deploying a similar
setup because they believed no one would use it.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some NOCs, even ones that support this on their network, don't understand
it...or at least have staff that don't even come close to grasping it. It
wouldn't surprise me at all if it's beyond a great many customers.
Too true. Their salesmen understand it even less and often categorically deny
they offer selective prepends despite evidence to the contrary.
Consider a network with several transit providers. Each transit pipe is
incapable of handling all that network's traffic. The pipes may even be
of wildly different sizes. Letting BGP decide where traffic goes (or
comes from) with no tuning just won't work. You'd end up with some pipes
overutilized and others underutilized. In this case, selective prepends
make it possible to shift traffic around or decide "we're going to try
forcing all ASxyz traffic to come to us over pipe A."
That's exactly the case where I work - some people suggest that you just buy
the pipe to suit the traffic that comes down it, but that doesn't really work
as there can be quite sudden shifts in traffic from one provider to another.
Customer controlled selective pre-pends offer a way to combat this effectively
and in a controlled manner. It does take time to get to grips with them and
the effects the changes you make have but in our case there is no way that
our upstreams could or would be willing to manage this for us.
However I must admit that as the number of prefixes we announce has grown it
has become a little easier to manage the scenario where upstreams don't
provide this level of control although it is still extremely useful where it
is provided. When we only had one or two prefixes it would have been very
tempting for us to de-aggregate our address blocks without the control
provided by the selective prepend mechanisms we had available to us. (A
temptation I'm glad to say we were able to resist)
And as for the suggestion that managing different providers methods of
presenting communities is difficult - it's not - we use a generic script and
a mappings file for each provider which maps the effect we want to the
community tags required. For each route we announce we then choose the
annoucement profile we want per transit - the script then generates the
appropriate config for each router.
Regards
Mark
- --
Mark Vevers. mark@ifl.net / mark@vevers.net
Principal Internet Engineer, Internet for Learning,
Research Machines Plc. (AS5503)
- --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB08F3CA3
Fingerprint: 85BA 30C4 9EC8 1792 4C8C C31E 58B5 3D1C B08F 3CA3