Upstream BGP community support

Hi,

Quick question: Would you buy transit from someone who does not
support BGP communities?

Here is the story:

My company is pushing several GBit/s through various upstream
providers. We have reached the point where we rely on BGP communitiy
support, especially communities that can be sent to the upstream to
change the way he announces our prefixes to his peers/transits.

While most decent upstream providers support this kind of traffic
engineering, one of them refuses to send and accept BGP communities. I
tried to contact my upstream several times through different channels
to get some background as to why they would not be able to provide us
this service, but all we get is tickets that get closed without an
answer. Management itself does not seem to bother either.

Is this normal or is it too much to ask for BGP communities from an
upstream who has points of presence in the US, Europe and Asia?

Andy

We have transit through Peer1 and Telia, both accept communities. I
wouldn't consider buying from someone who didn't.

Jeff

Yes and no. There are a handful of old stodgy networks who are of the
belief that this kind of information is "proprietary", and therefore
should not be sent to customers or other networks on the Internet. My
opinion is that those networks are "idiots", and therefore money should
not be sent to them.

Even if (for whatever reason) you don't need a particular set of
features in BGP communities, I personally think that they are an
excellent indicator of the networks' general technical competence and
ability to work with them on a wide variety of other issues. In this day
and age a robust and functional set of communities should really be a
requirement for any network provider.

<shamelessplug>
There was also a NANOG presentation on a pretty reasonable design and
implementation of BGP communities for a service provider:

http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf
</shamelessplug>

No.

Yes and no. There are a handful of old stodgy networks who are of the
belief that this kind of information is "proprietary", and therefore
should not be sent to customers or other networks on the Internet. My
opinion is that those networks are "idiots", and therefore money should
not be sent to them.

I would not say that my upstream is an old stodgy network and
certainly will I not consider them as "idiots", because they seem to
know what they are doing. I'd rather say they are pretty ignorant when
it comes to some "advanced" customer requirements.

By "they", I am referring myself to Hurricane Electric. But you are
right: money should not be sent to them while they lack any kind of
BGP community support.

Even if (for whatever reason) you don't need a particular set of
features in BGP communities, I personally think that they are an
excellent indicator of the networks' general technical competence and
ability to work with them on a wide variety of other issues. In this day
and age a robust and functional set of communities should really be a
requirement for any network provider.

We're almost 2010. Hurricane Electric, please do something about it!

Andy

maybe bake them a cake?

-chris

Wow, really? I would never have guessed in a million years that HE would
have a problem supporting communities. Typically lack of community
support falls into one of two categories.

1) Old stodgy tier 1's who have communities but don't want to share them
with the world, because of silly NDA concerns or the like. This covers a
wide variety of positions, from "we won't export them to anyone" to "you
have to sign some paperwork and/or yell a lot to get the secret decoder
ring".

2) Those who lacks communities completely. IMHO both are idiots, but
category #2 is a special breed which you should avoid like the plague. A
common problem for service providers who lack communities is the
inability to control their advertisements properly. Consider what
happens when they have a multihomed customer who typically announces a
prefix through them, but who decided to stop for some reason. They then
end up hearing that prefix via some other route, such as a peer or
transit provider, but without a community tag to know that it wasn't
learned from a customer they will blindly readvertise it, providing
unintentional (and typically unwanted) transit.

I'm curious, since when did respecting bounds of contracts and agreements
one has signed become "stodgy"?

-dorian

Andy B. wrote:

I tried to contact my upstream several times through different channels
to get some background as to why they would not be able to provide us
this service, but all we get is tickets that get closed without an
answer. Management itself does not seem to bother either.
  
Completely separate from your question about BGP community support policies, the quoted text above is a stopper for me. Any company that wants my money shouldn't close tickets without an answer - about anything, ever. This is a huge customer support red-flag issue for me. As always, YMMV.

jc

There is no excuse for not being able to tell people where you learned a
route from (continent, region, city, country, etc). I'm personally of
the opinion that this is a good thing to share with the entire Internet,
as it lets people make intelligent TE decisions for your routes even if
they don't have a direct relationship with your network. You should also
be able to at a minimum allow no-export or prepend to specific ASNs, and
not being able to provide these to customers is absolutely grounds for
"should never ever buy from" status.

The "we aren't allowed to say we're a peer" argument seems easily
defeatable, realistically if you're a stodgy tier 1 all you need is
"this is a customer" tag and you can figure out the rest with "not a
customer" logic without explicitly violating any NDAs. The "alter export
attributes within a specific region" argument is a somewhat legitimate
one due to requirements for consistent announcements, but I prefer to
enable it by default and deal with unhappy peers on a case by case
basis.

while i can understand folk's wanting to signal upstream using
communities, and i know it's all the rage. one issue needs to be
raised.

bgp is a brilliant information hiding protocol. policy is horribly
opaque. complexity abounds. and it has unfun consequences, e.g. see
tim on wedgies etc.

and this just adds to the complexity and opacity.

so i ain't sayin' don't do it. after all, who would deny you the
ability to show off your bgp macho?

just try to minimize its use to only when you *really* need it.

randy

Here is the problem as I see it. Sure some % fo the people using BGP
are bright nuff to use some upstreams communities, but sadly many are
not. So this ends up breaking one or more networks, who in turn twist
more dials causing other changes.. rinse, wash and repeat. But like
Randy said who am I to stop anyone from playing... just means those of
us with clue will be able to continue to earn a pay check for a very
long time still :slight_smile:

-jim

This is a strawman argument. I never said that any of the above was
a bad thing, nor that transit providers shouldn't support them. They
should.

Only point I was addressing was your characterisation that networks
who do support various communities but do not publish those supported
communities were "stodgy" becuase they were doing so due to "silly NDA
concerns or the like".

Fact is, regardless of whether you or I think it makes any sense or
not is that some peering agreements preclude disclosure of the locations
of peering, and in some extreme cases even the disclosure of the
existance of said peering.

So if you were a party to such an agreement, you can not disclose things
you are bound from doing without breeching the agreement.

Apologies to the list for the derail,

-dorian

Here is the problem as I see it. Sure some % fo the people using BGP
are bright nuff to use some upstreams communities, but sadly many are
not. So this ends up breaking one or more networks, who in turn twist
more dials causing other changes.. rinse, wash and repeat. But like
Randy said who am I to stop anyone from playing... just means those of
us with clue will be able to continue to earn a pay check for a very
long time still :slight_smile:

i would rather earn it by designing things, not by cleaning up messes
made by kiddies needing to show off.

randy

Agree'd :slight_smile:

Ok I think we're commingling issues. As I said in my first message, I
apply the stodgy label to folks who won't export any communities at all
because they're considered "proprietary". In my second message I was
trying to expand on their considerations (i.e. NDA concerns), which
didn't come across well. Clearly there are a large variety of
communities you can support which don't come with any such concerns.

Obviously any time NDAs are involved you have to give them some serious
consideration, but the question becomes at what point does an excessive
concern start degrading the quality of service you provider to your
customers for no reason.

My opinion is that an NDA preventing you from disclosing who you peer
with and in what locations means you shouldn't put up a website with the
address of every interconnection address and capacity, not that you
can't say "this route goes to the Chicago region". At a certain point
there is only so much information you can obscure. I'm going to be able
to figure out who your customers are when I see you readvertising them
to the Internet. I'm going to be able to figure out where you peer
because I can read the DNS in your traceroute and then walk around the
major colo facilities until I see your router with the label on front,
does this mean you can't use reverse DNS or label your routers? At some
point all you're doing by obscuring most of this information is making
it harder for me the customer, peer, or remote party who just happens to
be exchanging information with someone on your network, resulting in
poorer quality service for your customers.

And I'll conclude my argument with this:

whois -h whois.radb.net | grep remarks:

If Level 3 can tag routes with pop codes, cities, and peer/customer
origin tags, then you (for some value of you by which I mean anyone who
might ever get the stodgy label :P) can too.

Err insert "AS3356" in there, sorry failure in proofreading. I'll leave
it there, but clearly this is being done by many other large networks
without the world ending. And if you're a stodgy network reading this,
maybe this explains where all your customers are going. :slight_smile:

Being the architect/head-nerd-in-charge of a fairly new network.....

Not reading ras's HOWTOs and others is suicide.... There's no
excuse... It really makes running your network easier.. If my customer
needs to prepend X to Y transit/peer/customer or not announce to them
at 3am, that means they don't have to call me...

My customers like it, and so do I. RTFM and we'll all be happier...

That's exactly what I expect from a decent upstream.
So far all our upstreams (Level3, Cogent, Tata), with the exception of
HE, provide this service.

I don't even care about receiving their communities which describe
where the prefix has been injected, since I can handle outbound
traffic more or less myself. It's a nice-to-have feature though.
It's the inbound that I cannot control without a little help from my
upstreams, hence our desperate need to send BGP communities.

Andy

The answer is fairly simple. Does your business benefit by having the ability to modify routing strategy as you see fit?

Yes or no?

IMO, the answer is yes. If your business partners aren't on the same page or align correctly with your requirements, seek new ones.

tv