Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)

["Sriram, Kotikalapudi" <[e-mail]>]

Sue,

Thank you. I welcome the cross-review, assuming GROW WG chairs are OK with it.

Sriram


>-----Original Message-----
>From: Susan Hares [mailto:[e-mail]]
>Sent: Tuesday, August 25, 2015 5:07 PM
>To: Sriram, Kotikalapudi <[e-mail]>; 'George, Wes'
><[e-mail]>; 'Christopher Morrow'
><[e-mail]>; [e-mail]; grow-
>[e-mail]; [e-mail]
>Cc: 'John G. Scudder' <[e-mail]>
>Subject: RE: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
>(ends: 8/24/2015 - Aug 24)
>
>Siram:
>
>Do you want me to post this for a cross-review in IDR?
>
>Sue Hares
>
>-----Original Message-----
>From: GROW [mailto:[e-mail]] On Behalf Of Sriram, Kotikalapudi
>Sent: Tuesday, August 18, 2015 8:18 AM
>To: George, Wes; Christopher Morrow; [e-mail];
>[e-mail]; [e-mail] [e-mail]
>Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
>(ends: 8/24/2015 - Aug 24)
>
>Thank you, Wes.
>The comments you've offered are greatly helpful for improving accuracy as
>well as clarity in what is being said.
>I plan to incorporate them in the next revision (v. -03) soon.
>
>Sriram
>________________________________________
>From: GROW <[e-mail]> on behalf of George, Wes
><[e-mail]>
>Sent: Monday, August 17, 2015 2:45 PM
>To: Christopher Morrow; [e-mail]; [e-mail];
>[e-mail] [e-mail]
>Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
>(ends: 8/24/2015 - Aug 24)
>
>I've reviewed the latest version, and generally think that it is ready to
>proceed once the below comments are addressed. A cross-review from IDR
>might
>also be useful before it goes to IETF LC.
>
>There are several areas in Section 3 where you use attack and leak
>interchangeably in a way that adds a bit of confusion. I think it'd be
>better to pick one and stick with it, probably leak rather than attack, and
>only use attack if you are describing something that is almost always
>malicious rather than accidental.
>I.e.
>attack type 1 - "The update basically makes a
>      U-turn at the attacker's multi-homed AS.  The attack (accidental
>      or deliberate) often succeeds"
>Previously, you say that you refer to the leaking AS as the "offending AS".
>I'd suggest using that here instead of "the attacker's". Similarly, you've
>already said that most leaks are unintentional, so it might be better to
>simplify that next sentence by saying "the leak often succeeds"
>and eliminate the parenthetical. It is also unclear from the text exactly
>what you mean by U-Turn (it's not going back the way it came, so actually
>hairpin might be a better term), so a few words to clarify might be useful.
>Type 2 - "Update is crafted by the attacker...success of the attack" - same
>comment here about attack vs leak vs offending AS
>
>Type 4 - While often the increase in prefixes causes its own problems
>(dramatically increased routing table size, exceeded max prefix limit,
>etc) you may want to add some text to the effect of "these more specifics
>may cause the routes to be preferred over other aggregate announcements,
>thus redirecting traffic from its normal best path" as that makes it clearer
>what the impact of the leak is in this case.
>
>Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically
>peering" really add a lot to the explanation. The rest of your text sounds
>more like you're describing a non-transit relationship (typically only
>announce their customer routes to each other), which I think would be an
>easier term to define and more likely to be something readers would be
>familiar with. Either way, the explanation in this section could benefit
>from a good editing pass for clarity.
>
>Type 6/7- "its provider" - do you mean its transit provider? Otherwise it's
>unclear what distinguishes this from type 5, and again would be useful to
>use transit/non-transit to clarify.
>
>Also, an editorial nit/personal preference: since there are so few sections
>to this document, it might be useful to take each of the subtypes and make
>it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to
>refer to it in text and reviews - subsections can have HTML anchors so that
>you can link right to them, and they show up in the table of contents as
>well.
>
>Thanks,
>
>Wes
>
>_______________________________________________
>GROW mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/grow