On 1/Aug/20 22:29, Ryan Hamel wrote:
Job,
I disagree on the fact that it is not fair to the BGP implementation ecosystem, to enforce a single piece of software to activate the no-export community by default, due to ignorance from the engineer(s) implementing the solution. It should be common sense that certain routes that should be advertised beyond the local AS, just like RFC1918 routes, and more. Also, wasn't it you that said Cisco routers had a bug in ignoring NO_EXPORT? Would you go on a rant with Cisco, even if Noction add that enabled checkbox by default?
Why are you not on your soap box about BIRD, FRrouting, OpenBGPd, Cisco, Juniper, etc... about how they can possibly allow every day screw ups to happen, but the same options like the NO_EXPORT community are available for the engineer to use? One solution would be to implement "BGP Group/Session Profiles" (ISP/RTBH/DDOS Filtering/Route Optimizers/etc) or a "BGP Session Wizard" (ask the operator questions about their intentions), then automatically generate import and export policies based on known accepted practices.
Another solution could be having the BGP daemon disclose the make, model family, and exact model of hardware it is running on, to BGP peers, and add more knobs into policy creation to match said values, and take action appropriately. That would be useful in getting around vendor specific issues, as well as belt & suspenders protection.
Most (if not all) people buying BGP optimizers aren't using them for regular BGP-speaking routers to the rest of the Internet or their core network. BGP optimizers serve a unique use-case, which works in the way it does to create an expected risk as we saw in this and past incidents. On that basis, I think Job's request to make NO_EXPORT a mandatory default (I'd go further to say the new default mode can be user-disabled, but with an unmistakable warning in the UI) is not unreasonable. Mark.