Network A was sending more routes into the route server than Network B could handle. Network B would like Network A's routes filtered before they even got to their router. Googling a bit I saw pages talking about saving CPU or what have you, but the main thing was Network B has a limited FIB. They have a prefix limit specified to protect that. Their device goes through prefix limit before prefix filter, so their filters wouldn't even see the advertisements as the prefix limit already killed the session. Raise the prefix limit so that the filters can get to work and now you're vulnerable to someone else injecting a ton of routes and melting their router. If that draft were supported by Network B's router and the route servers, I believe that Network B could tell the route servers to filter Network A's prefixes before sending them, thus saving their FIB. Obviously the most correct answer is for Network A to get routers with big enough FIBs, but that's not always possible or practical. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Job Snijders" <job@instituut.net> To: "Mike Hammett" <nanog@ics-il.net>, "NANOG" <nanog@nanog.org> Sent: Sunday, October 22, 2017 5:29:33 PM Subject: Re: AS-Path - ORF Draft Hi Mike, On Sun, 22 Oct 2017 at 20:45, Mike Hammett < nanog@ics-il.net > wrote: https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13 Not knowing anything about the draft\RFC process (and not really wanting to go beyond a 30k foot view), is this something with movement? Traction? This would have solved a situation I encountered a week ago. <blockquote> </blockquote> Can you describe the situation in more detail? Kind regards, Job