On Tue, May 28, 2019 at 9:27 AM Job Snijders <[email protected]> wrote: > Dear working group, > > We've received a handover draft from IDR - the draft was moved to GROW > because it no longer specifies changes to the BGP protocol, but now > specifies operational procedures. Earlier versions of the draft relied > on a BGP Path Attribute. > > you can read the draft here: > > > https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation > > Your comments and feedback are welcome - if there is sufficient traction > we can move the document forward in the publication pipeline. >
I am in favor of this. NB: I am co-author, and also co-author of the earlier work detailing what a route leak is and how to know if something is a leak. As the very recent China Telecom incident shows, these problems are relatively common and won't stop by themselves. This draft proposes a very simple and IMNSHO elegant way using a couple of Large Community ranges that are easy to apply and use. This is a fairly mature work at this point, notwithstanding some re-organizing of the draft and trimming it for ease of review. Please take a look and, if you think this is an important problem to fix (route leaks), add your voice here. Thanks, Brian P.S. Recent incident coverage, written up quite nicely: https://blogs.oracle.com/internetintelligence/large-european-routing-leak-sends-traffic-through-china-telecom P.P.S. I suspect that for widespread useful adoption, it will be necessary to augment (Job's?) previous stuff on requiring an explicit non-default BGP config to enable BGP sessions, to add an on-by-default sending of well-known-communities and these new ranges of reserved-for-this-purpose communities. But, that's subsequent work, and also safe, and a no-brainer, IMHO.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
