Skip to main content

Telechat Review of draft-ietf-grow-route-leak-problem-definition-04
review-ietf-grow-route-leak-problem-definition-04-genart-telechat-resnick-2016-06-23-00

Request Review of draft-ietf-grow-route-leak-problem-definition
Requested revision No specific revision (document currently at 06)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-05-03
Requested 2016-04-12
Authors Kotikalapudi Sriram , Doug Montgomery , Danny R. McPherson , Eric Osterweil , Brian Dickson
I-D last updated 2016-06-23
Completed reviews Genart Last Call review of -04 by Pete Resnick (diff)
Genart Telechat review of -04 by Pete Resnick (diff)
Opsdir Last Call review of -04 by Carlos Pignataro (diff)
Rtgdir Early review of -04 by Mach Chen (diff)
Assignment Reviewer Pete Resnick
State Completed
Request Telechat review on draft-ietf-grow-route-leak-problem-definition by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 06)
Result On the Right Track
Completed 2016-06-23
review-ietf-grow-route-leak-problem-definition-04-genart-telechat-resnick-2016-06-23-00

I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments just

like any other last call comments.

For more information, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

.

Document: draft-ietf-grow-route-leak-problem-definition-04

Reviewer: Pete Resnick

Review Date: 2016-03-21

IETF LC End Date: 2016-03-28

Summary: This draft is on the right track but has open issues, described in
this review.

Major issues:

None.

Minor issues:

Figure 1, along with the discussion of it in section 3, was confusing to me.
First of all, am I correct that the example displays

two

 leaks? That is, there's the leak from AS3 to ISP2, and then there are the
 propagated leaks from ISP2 to the rest of the world. Also, "(P)" seems to be
 used as both a leaked prefix (from ISP1 through AS3 to ISP2 and then
 propagated from there) as well as what looks to be a normal prefix update
 between ISP1 and ISP2. Are all of the occurrences of "(P)" in Figure 1
 identical? Or is the prefix update between ISP1 and ISP2 also a leak? What
 leaks is Figure 1 intended to show?

In 3.1: "The leak often succeeds because...". Do you really means "succeeds"
and not "occurs"? If so, what does "succeeds" mean in this context?

The description in section 3.5, starting from "However", really needs a
complete rewrite. It's ungrammatical to the point that I'm not really sure I
understand what it is trying to say.

Nits/editorial comments:

I've mentioned before that I find the "academic research paper" style a bit
jarring in IETF documents. I particularly don't like the use of "we" and "us",
since it's not clear whether "we" is the authors (which is how it's used in
academic papers, but is inappropriate for an IETF document), the WG, the IETF,
etc. Instead, I would replace all instances of "we" with "this document", or
simply re-word into the passive, since a subject is rarely needed for these
sentences. For example, the abstract could be rewritten as such:

A systemic vulnerability of the Border Gateway Protocol routing

system, known as 'route leaks', has received significant attention in

recent years.  Frequent incidents that result in significant

disruptions to Internet routing are labeled "route leaks", but to

date a common definition of the term has been lacking.  This document

provides a working definition of route leaks, keeping in mind the

real occurrences that have received significant attention. Further,

this document attempts to enumerate (though not exhaustively)

different types of route leaks based on observed events on the

Internet.  The aim is to provide a taxonomy that covers several forms

of route leaks that have been observed and are of concern to Internet

user community as well as the network operator community.

Please do similar edits throughout.

Similarly, the referencing of authors by name seems like bad form for an IETF
document.

OLD

   This document builds on and extends earlier work in the IETF by

   Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-

   leak-reqts].

NEW

   This document builds on and extends earlier work in the IETF

   [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-leak-

   reqts].

END

OLD

                             Mauch [Mauch] observes that these are

      anomalies and potentially route leaks because very large ISPs such

      as ATT, Sprint, Verizon, and Globalcrossing do not in general buy

      transit services from each other.  However, he also notes that

      there are exceptions when one very large ISP does indeed buy

      transit from another very large ISP, and accordingly exceptions

      are made in his detection algorithm for known cases.

NEW

                             [Mauch] observes that these are anomalies

      and potentially route leaks because very large ISPs such as ATT,

      Sprint, Verizon, and Globalcrossing do not in general buy transit

      services from each other.  However, it also notes that there are

      exceptions when one very large ISP does indeed buy transit from

      another very large ISP, and accordingly exceptions are made in its

      detection algorithm for known cases.

END

Last paragraph in section 2: I'm left wondering what sorts of things that other
folks might consider leaks

aren't

 covered by the definition. Perhaps you want to mention that?

In 3.6, when you say "more specifics", are you using that as a noun to mean
"more specific prefixes"? It's very hard to read in its current form.

Section 5 is superfluous. I'd delete it.

On a side note, I must say that the writing style of the "Example incidents"
caused me quite a bit of giggling. "Examples include symmetrical book stacking,
just like the Philadelphia mass turbulence of 1947, and the biggest
interdimensional crossrip since the Tunguska blast of 1909 [GhostBusters1984]."
Reading them aloud helps. :-) (No need for a change; they're fine as is. They
just sound funny to a person not in the field.)

pr

--

Pete Resnick

http://www.qualcomm.com/~presnick/

Qualcomm Technologies, Inc. - +1 (858)651-4478