-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Alejandro,
On Tuesday, 22 July 2025 at 13:56, Alejandro Acosta <[email protected]> wrote: > Hello James > > Can you elaborate this is a little bit more?. Why do you think Local Pref > should be avoided? Sure. Just to be clear, I am approaching this from the perspective of an IP transit provider, maybe you’re coming from a different perspective where LP makes more sense? As a transit provider I don’t want to use LP to prefer one path other another because LP is evaluated before AS Path and MED. ASP and MED are attributes which show the actual path details (how long it is, and how “expensive” it is to use this path). In an inter-domain routing system, making routing decisions NOT based on visible details (ASP and MED), but invisible details (LP), means we can’t trust the visible details any more. So the first problem with LP is that LP isn’t received from, or advertised to, my eBGP peers. If I am receiving a path which was chosen by my peer because of their LP, I can’t see that, I only see the ASP and MED, so it’s unclear to me why a path was chosen (the same with paths I advertise, the eBGP peer received a path from me which based on the path attributes, LP and MED, doesn’t look like it should be the best path). The visible attributes became useless in understand which paths to take. Secondly, and this is a big one for me, LP removes the ability for my customers to influence routing to their own ASN. If I set the LP on their port, they can manipulate the MED and AS Path but I will ignore this. E.g. I am a 2nd upstream to my customer, they prepend to me so I’m their backup provider. The old-school telco mentality was to have a higher LP on customer ports. So as a result, I would always send traffic from my peers, down to my customer. Forcing my customer to pay me for delivering this traffic to them, even though they have signalled via AS-Path prepending and/or increased MED, they want me to be their backup provider. So I took away from them the option to control their own traffic flow (by using LP). I am well aware that the whole point of LP is that there may be cases where despite one path having more preferable path qualities (shorter ASP or lower MED), it’s less preferable than another path due to having lower bandwidth, higher latency, costs more money, etc. Therefore LP *could* be used here. But I could also just increase the MED on the received path, or prepend the ASN. This remains visible when I forward this route externally to my eBGP peers and achieves the routing goal of de-preferring the higher latency link. There is also a third reason which is the operational headaches that LP tuning introduced. The old school telco mentality is (roughly); customer ports have best LP, peers/IXP ports have 2nd best LP, transits ports have 3rd best LP. Most telcos offer BGP communities for changing the LP, but as mentioned, LP isn’t received by any eBGP peer of the telco, so nobody can see why this route has been chosen. Each telco is using their own non-standardised set of of BGP communities for LP manipulation so it’s not easy to understand just from looking at the BGP data what the communities attached to a route mean/do. Some telcos have looking glasses, but not all, and of those that do, not all of them show LP. So it just becomes much more painful for daily operations in comparison to use ASP and MED. I hope that makes it clear why LP is not ideal from my perspective. With kind regards, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJojbRyCZCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnNL4+azHjxhhjgkpQ55GB2XHh3GRa1C/EcTwa 0ZGXsNMWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAf1IQAJGK2DNQt8lFnY+Y cSJUeNNtfTkWs0nzbV4HbpByYzUVJeBCTUQZ/C0YOX3GdB5Gk5lsUl4jP5tw D5kLU5BZ7fUUOlTXsZpNmgCx78J2Dj5kR/OT7tu6Bg3zAOg8h8djiZAM6WP2 h7jSf1nv3V8IyA2RYNI2fMNQvLF/KSOxaGGhzS3MEJJNodBwVRvwMZd2hD2I v/n41ZJ6Fj8XJPubL61yQafLlJthYaT7PtaAZT9RZ3UrzVsFIFlhgaKxxV/c JRHYgl1d+6KhgrBQr7CQGCEE2WEW5nC5E3y7fyzwS8XLO9UMaBm404MaXDp/ VmD8Yo0R6zSRl6Ednb1vWiCXPfVujei1sfA4GkVAuUVJo1PjB3tzilyMqoJe kkVmiwXJ/JoJEfpOd/c4pvMhWRwXG++CJxfMZ4zyNYNyoSgK3srt+bRCkfDr NmwiY8QTQxSUz95b6jAzbLXoOP1dJhcnZ+s7bdDFs/nitYdSTF8IdLcUeOLg o0SKuSKt52FL/oGmPSRDIvcNR7s73KnCThrQleM/bdM5zhF3YEOXtrdpn6mf D25hPlY1MG1FCLTEHlgVk2F8xSM+GqUdQ8V9LZ/QpW4KMmyfoHwsJzYI9Hoz /v8ArNidew3kt8S5tfjAS/bt1U32XUMKF0y9ldv0pdFoOCynPWHS3+RzYton e6N5Krg6 =C1Bd -----END PGP SIGNATURE-----
publickey - [email protected] - 0x3E936359.asc
Description: application/pgp-keys
publickey - [email protected] - 0x3E936359.asc.sig
Description: PGP signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
