On Nov 26, 2013, at 4:24 PM, Geoff Huston <g...@apnic.net> wrote: > I reviewed the mailing lists of all three WGs from November last year, when > this came up. > and I was searching for a proposed methodology of defining requirements, > proposing mechanisms > and standardising one of more candidate technologies relating to the issue of > path > control of the propagation of BGP announcements in order to allow BGP speakers > to detect unintended announcements. My search of the list archives was > unsuccessful. > > As I seem to be the only one interested in an answer, I give up.
At $dayjob, we have a list of ASNs that we shouldn’t see from our customers. We work to update our AS_PATH filtering to match these as the network evolves. Our AS_PATH filtering may be different than your list. The biggest problems I’ve seen/observed are: a) People put stuff into an IRR and it never comes out b) Routers lack sophistication in configuring policy (or the configured policy blows out its config/memory/structure space) c) Customers will pay to not be filtered at all d) Networks don’t care to address issues (e.g.: AS-FLAGT expands to how many routes?) This is a hygiene issue like showering and brushing your teeth. Vendors figure it’s an operator problem (then freak out when we show them the scale). Customers and peers don’t address the tragedy of the commons. We’re left with little traction to put ourselves on a trajectory for a fix as the average BGP speaker is an IOS devices that still today sends/receives all routes learned by default with no policy configured. - Jared _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
