Notifying customers of upstream modifications
tom at ninjabadger.net
Wed Dec 28 18:44:53 CST 2011
On Wed, 2011-12-28 at 17:59 -0500, Andy Susag wrote:
> If you add or remove an upstream provider to your network, do you
> provide notification to your downstream customers? Likely, it would
> cause a shift in their traffic. If they are peering with multiple ISPs
> themselves, they may see a traffic flux.
We raised this question recently. The answer (from those with seniority)
was that we sell "IP transit". We do not specify where it comes from or
how it's made; beyond what a sales person may say to clinch a sale, the
contract does not mention our upstreams, only that we agree to transit
traffic to/from their ASN at an agreed rate per mbit.
The point came that if anyone whom requires BGP transit also *requires*
the fastest possible connectivity to a particular ASN (3356, 20940,
etc.) then they can always buy transit/peer with that ASN separately. In
most cases, this would also be preferable to taking blended tier-1
transit from a tier-2 (or however you describe that.)
> I know for a fact that our upstreams do not notify us of events so we
> tend to not send out these sort of notifications. Just wonder what
> everyone else does or if anyone happens to know "best practice"
*cough* Cogent. Perfect example. Automagic
de-peer^H^H^H^H^H^H^Hblack-holing happens without prior warning,
notification OR explanation.
And it's the same answer. We buy transit, we don't specify whom they
must be connected to.
Morally I agree that it would be nice to tell your customers.
Practically, I don't believe you can win. I mean, would you tell your
downstreams every time you bring-up a new peer? That's not _always_
going to be positive for them.
The answer, speaking as a downstream and a transit provider, is to just
peer where you need guaranteed connectivity. If change is a problem to
your customers, they don't understand how BGP works and they need to cut
out the middle-man.
More information about the NANOG