On 8/Jan/20 16:26, James Jun wrote:
I get that you'd want to reset MED on peering sessions, but any particular rationale on why you'd rewrite MED to 0 on customer sessions?
I would argue that providing the ability for customers to transfer backhaul costs onto their transit provider is one of the compelling commercial reasons *for* IP transit vs. other modes of IP interconnection.
Conversely speaking, I would also argue that transit provider *should* forward meaningful MED values on its route advertisements to customers. If a customer wants to cold potato his outbound traffic on his own network, that's entirely his call; he has the option of rewriting MED to 0 if he wants closest exit to his transit instead.
Most transit providers (at least in US, I can't imagine it's much different in EU) will permit downstream customers to cold potato traffic through their network.
We provide customers with a ton of LOCAL_PREF options they can activate in our network via communities: http://as37100.net/?bgp As I mentioned to Saku re: the ORIGIN attribute, I don't mind customers using this on us since we have sufficient backbone capacity in all markets, and they pay us to provide them with a port in each market. So if customers want to change our LOCAL_PREF values in order to push traffic some way or another, we are okay with this, since it's $$. Mark.