BGP Path Attribute Filtering, YES or NO?

Wed Jan 8 14:31:36 UTC 2020

On 8/Jan/20 15:49, Saku Ytti wrote:

>
> If you reset MED in effort to stop me from transferring my
> infrastructure costs to your network, I can still set origin and force
> cold potato in your network.

Okay, I see how this could be abused in a scenario where you have
multiple peering locations with a single network.

Looking at our own network specifically, I'm not immediately seeing a
risk of this (will look a little deeper in the next couple of hours) as
the only location where we may be peering in multiple locations with the
same network across a vast geographic scope is Europe. Specifically,
AMS-IX, DE-CIX, ECIX, France-IX, LINX and NL-IX. Considering the scope
of our European backbone, I don't see any obvious benefit to a
multi-homed peer given the rather contained latency between these
cities, and the average cost of capacity on the continent.

We specifically refuse to have multiple transit locations with
upstreams, partly because of this and also because we already have a
transit compliment that works well for us. So for every transit provider
we have, that would be in a single location.

The other location where we peer with the same provider in multiple
locations is South Africa (Johannesburg, Cape Town, Durban). Considering
that we have a Selective peering policy, we can manage any issues here
that may crop up, and they can come up very quickly and noticeably
considering South Africa has 2 major exit points, west via Cape Town and
east via Kwazulu Natal. I could see where a peer may decide to
cold-potato us between the 3 major cities, on-land, but there are
"social" reasons why this is not likely (buy me a beer, hehe), apart
from being quickly noticeable by our NOC and customers (including their
NOC and customers).

I can see how one transit provider could use the ORIGIN attribute to
force my network to send more traffic toward them vs. my other transit
providers. However, that would require that at least one or more of the
other transit providers set their ORIGIN code to EGP or Incomplete, so
that the default of IGP works toward their objective. Otherwise, setting
anything other than IGP, when the rest leave it default, actually
increases their potential to lose my traffic.

For customers trying to do this, I'm not sure I really care since they
are paying us for any and all ports they have with us, if multi-homed to us.

I guess I'm just battling with my mind as to whether going back to
retrofit the network with "set origin igp" explicitly is worth it. For
the moment, not yet, in our specific case (might be a different case if
we had a large North American network), but I'll keep chewing on it.

Mark.