Nick, I understand there are rules and unspoken guidelines/rules for the DFZ, but when it comes to each individual AS, that org/operator can run their AS internally however they please, and maybe they have considered the risks you have mentioned. That said, I can argue that upstreams not filtering their customers properly removes a safety guard, upstreams not implementing RPKI removes a safety guard, not properly prepending communities on synthetic routes to drop them on export again removes a safety guard. I can go on... * As an industry, we should be well beyond the point of having to tell people that this is a poor idea, in the same way that we don't need to tell people that bypassing electrical fuse boxes is a poor idea, or removing railings on stair-cases, or not wearing motorbike helmets, or anything else designed to mitigate the unfortunate consequences of entirely predictable accidents. Where this statement falls short is, those are all regulated by building codes, laws, etc. No laws exist dictating how BGP, routing protocols in general, and topologies must be implemented, nor what safety guidelines must be adhered to. Ryan Hamel ________________________________ From: Nick Hilliard <nick@foobar.org> Sent: Friday, December 6, 2024 8:34 AM To: Ryan Hamel <ryan@rkhtech.org> Cc: Tom Beecher <beecher@beecher.cc>; nanog@nanog.org <nanog@nanog.org> Subject: Re: Route optimization using GPUs? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Ryan Hamel wrote on 05/12/2024 23:45:
What does "these devices don't follow standard BGP behaviors" have to do with adding a NO_EXPORT or specific community on the import policy when a route is accepted, and being belt & suspenders with matching those communities to drop those routes on export to carriers/IX/PNI sessions?
Ryan, BGP ensures loop-free interdomain path computation by inspecting the AS path of each NLRI. If a routing optimiser rewrites all the AS paths for all the NLRIs it receives, then it's just pooped all over the primary component of BGP that's designed to ensure that interdomain BGP actually works in the way that it's supposed to do in the first place, which also acts as an intrinsic safety guard against dfz hijacking. Removing an intrinsic safety guard like this is an inherently risky thing to do. When you elevate the inherent risk of a system, you necessarily elevate either the likelihood of failure or the consequences of a failure, or both. As an industry, we should be well beyond the point of having to tell people that this is a poor idea, in the same way that we don't need to tell people that bypassing electrical fuse boxes is a poor idea, or removing railings on stair-cases, or not wearing motorbike helmets, or anything else designed to mitigate the unfortunate consequences of entirely predictable accidents. Nick