Jeff, Thanks a lot for your comments and support. Just submitted a version-03 draft in which your suggestions/comments have been incorporated. Also, please see responses below.
>Please consider updating the "replaces-by" for the draft to the original >draft-sriram... I think that is a comment for the chairs. >In general, this document is clear and very well written. It does an >excellent job at summarizing the landscape for route-leaks and provides lots >of citations (which I haven't validated for >correctness vs. the issues) for study. Thank you for the kind compliments. >The majority of my comments are minor terminology tweaks, some additional >explanations which might or might not be useful content and one discussion >point for re-organizing some of the types. >I'm supportive of this document moving forward even if my comments were not >immediately addressed. Thank you. Your comments have pretty much all been addressed in the revised -03 version just submitted. >In your section on "type 2", where you use the term "aggregates", consider >normalizing your terminology on "more specific" and "less specific" routes. >While aggregate is semantically clear in this section, aggregation is often >considered in the context of taking multiple more-specific prefixes and >generating a new, less specific prefix. Done. I now use the "more specifics / less specifics" terminology per your suggestion (avoided using "aggregates" where ever not relevant). >Type 3 attacks may also be called a "re-origination" attack. Consider >working that into the text, please. Done. >Similar to my comment on type 2, Type 4 is treating the matter as a >"de-aggregation" rather than simply announcing internal more specific >routes. Some of this is perspective, as seen by a receiver, but >understanding the issue is perhaps better done >from the perspective of the originator. Done. Changes made in the document accordingly. >One source of type 4 issues have included how some older vendor implementations >handled its configuration, leading to a trasient announcement of the more >specifics. A related one may be related to intentional generation of less >specifics from internal more specifics. In this case, routes contributing >to the aggregate are configured with policy that is intended to suppress >contributing routes, but such policy is only effective after the less >specific aggregate route is created; this creation may lag for various >implementation reasons. Thank you for sharing the insight. I understand it is not meant for making changes in the document. >Consider s/prefix-routes/routes/. The prefix- seems a bit redundant, at >least in a BGP routing context. The substitution has been made in the revised doc. >Types 5,6 and 7 are effectively forms of type 1. The only thing varying is >the *context* of the leaked route source AS and destination AS roles. >Perhaps it's worth considering re-grouping the four sections in a way that >highlights that? I have changed the Types list into Subsections (3.1. through 3.7) per Wes's suggestion. And then I reordered/regrouped those sections (Types) per your suggestion. Basically, I've put the types you noted above together (now they are Sections 3.1 through 3.4). Also, please see the related comment I have added in the 1st paragraph in Section 4. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
