Notifying customers of upstream modifications

Hi All,

Just a quick question for those of you running ISPs with BGP
downstreams.

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.

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"

Thanks,

Andy

In an ideal world, part of a good change-management process is to notify
those who may see differences as a consequence of any proposed change
(tell the folk that care). That way, they know something is moving and
can plan accordingly. Also they can advise in a timely fashion if it
either works or not and make their own changes when appropriate.

Sadly, we do not live in an ideal world :frowning:

  imb

Hi Andy,

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.

Tom

Most transit networks have some sort of blanket notification that they can
send to customers. Something like between 12AM and 6AM sometime next week
you may or may not have a moderate or severe impact, but we're not going to
give you details. It also depends on the peering that is being added or
removed. The larger providers are mostly static. I can't imagine Level 3
permanently depeering from Verizon for example. Also, if paths change but
latency and hop count are still acceptable most customers will not notice
the change. The same goes for outages. Also, where do you draw the line.
For example if someone severs a peering with a content network like google
some of their downstreams will care others will not. If ISP's notified
everyone of every change it would more or less become spam so I can see an
argument for both. In large transit networks it probably comes down to the
predicted impact of the a particular change versus visibility and
contractual liabilities.

Ding Ding Ding!