HE.net and BGP Communities

Mon Jul 25 18:33:39 UTC 2022

On Mon, 25 Jul 2022 at 16:23, Forrest Christian (List Account)
<lists at packetflux.com> wrote:
>
> I do understand the reasoning behind preferring customer routes.
> However in the case where a customer of a customer also
> connects to you directly via peering doesn't it make sense to prefer
> the direct connection?  or at least not prefer the customer learned routes.

No, I don't think it makes sense at all.

Not preferring customer routes over peering routes would mean:
- less revenue for HE
- less revenue for the HE customer (your transit provider)
- risk of upsetting the customer for the previous reason (less revenue)
- for your transit provider it would mean they would provide a transit
service with less redundancy (see below), less ingress-paths (see
below), and more complicated configuration (and therefore more complex
troubleshooting)

The only difference is that HE doesn't provide BGP communities for
your transit provider for TE. *But even if HE would provide THE
communities*, it's not in the best interest of your transit provider
to actually pass those BGP communities to HE or configure them for
you, because it would mean less traffic on revenue generating links,
so it would not make sense from a business perspective. It would also
likely require manual configuration of policies, which can be
difficult, undesirable or not possible at all, depending on the amount
of automation in that network.

> I don't remember why,  but we couldn't have the transit provider not announce our routes toward HE

And why would they send for your routes specifically or pass through
BGP communities to HE, when they are already refusing to withdraw
announcements to HE?

Businesses don't usually go the extra mile to make everything worse
for them (revenue, configuration and support complexity, redundancy,
performance due to amount of ingress paths).

HE is special in this regards for 2 reasons:

- HE doesn't provide TE communities for customers (which is bad and a
showstopper for some)
- but more importantly, HE has an open peering policy so they actual
peer with you in the first place; otherwise we wouldn't have this
discussion

There are a few technical aspects that to consider:

Once HE's best path is a peer route, as opposed to a customer route
(which is what you are asking), then those routes would not be
announced by HE to its peers anymore (after all, they don't exchange
peer routes with peers).

So you'd be worse off in some aspects, because your ingress traffic
wouldn't be attracted by HE's (vast) peering network anymore. Also if
you are single-homed to this transit-provider, and this
transit-provider also temporarily single-homes to HE (maybe for
maintenance one 1 of 2 transits), you'd be disconnected from pretty
much the rest of the internet (that doesn't have HE transit), until
you shutdown your HE peering. So less ingress paths, less redundancy,
etc.

There are good business and technical reasons for preferring customer
routes. Many networks don't even peer with customers of customers,
also for good reasons.

I don't think it makes any sense to consider a shorter as-path over
peering when it also comes from a customer (with a longer as-path).

- lukas