Nick, Thank you for your thoughts on this.
This work has been in GROW / IDR since 2014. Initially in GROW where we published a route leak problem definition RFC: https://tools.ietf.org/html/rfc7908 The work then moved to IDR for the route leak solution based on BGP Attribute. It was moved back to GROW lately because IDR Chairs and others (authors + Ruediger) felt that a solution based on Community would be deployable a lot faster -- in months as opposed to years. First, if you care you may offer your thoughts on Attribute vs. Community. Second, I would appreciate if you can offer concrete examples of the scenarios that you mention -- some examples where one saw those types of leaks occur in the real world. As for the basic principles on which the solution is based, we essentially decided that we could readily address route-leak Types 1 through 4 of RFC 7908. That is what the draft does. I don't think addressing route-leak Types 1 through 4 is narrow pigeon holing. As illustrated in RFC 7908, most real-world route leak incidents seem to fall in the six types identified in the RFC. The RFC lists many observed route-leak incidents and categorizes them. (Note: Types 5 and 6 are addressed by other solutions such as route filtering, RPKI, max prefix, etc.) The subnet leak that you mention (AS path intact or AS path removed) was discussed in GROW and it was decided that was NOT a route leak type -- OTOH subnet leak is only addressable with ROAs and/or BGPsec path validation. GROW WG decided not to include it in RFC 7908 (although it was included in earlier versions of the definition draft). Sriram ________________________________________ From: GROW <[email protected]> on behalf of Nick Hilliard <[email protected]> Sent: Saturday, June 15, 2019 6:22 AM To: Brian Dickson Cc: [email protected] Subject: Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation Brian Dickson wrote on 15/06/2019 00:42: > Please take a look and, if you think this is an important problem to fix > (route leaks), add your voice here. there are two things here: route leaks (important), and the proposal in draft-ietf-grow-route-leak-detection-mitigation. We can probably all agree that route leaks are a persistent threat. What concerns me about this draft is that it takes an over-simplified view of real-life networks and there's not a small amount of implied pigeon-holing going on. The difficult with the draft is that many networks don't fall into these neatly defined categories. There are back-doors, partial transit configs, PNI arrangements, subnet leaks and all sorts of weird things out there, none of which are easy to categorise, but which nevertheless make up an important part of the routing ecosystem. Characterisation of these edge cases is a difficult problem. I'm not convinced this can be done adequately without an expressive grammar (note: not rpsl). I'm also not convinced that the approach taken in draft-ietf-grow-route-leak-detection-mitigation is generic enough to be worth deploying. Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
