Skip to main content

Early Review of draft-ietf-i2rs-problem-statement-06
review-ietf-i2rs-problem-statement-06-opsdir-early-banks-2015-07-20-00

Request Review of draft-ietf-i2rs-problem-statement
Requested revision No specific revision (document currently at 11)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2016-02-16
Requested 2015-06-30
Authors Alia Atlas , Thomas Nadeau , David Ward
I-D last updated 2015-07-20
Completed reviews Genart Early review of -04 by Russ Housley (diff)
Genart Last Call review of -09 by Russ Housley (diff)
Rtgdir Early review of -06 by Dr. Nabil N. Bitar (diff)
Secdir Early review of -04 by Stephen Kent (diff)
Secdir Last Call review of -09 by Stephen Kent (diff)
Opsdir Early review of -06 by Sarah Banks (diff)
Rtgdir Early review of -04 by Eric Gray (diff)
Assignment Reviewer Sarah Banks
State Completed
Request Early review on draft-ietf-i2rs-problem-statement by Ops Directorate Assigned
Reviewed revision 06 (document currently at 11)
Result Ready
Completed 2015-07-20
review-ietf-i2rs-problem-statement-06-opsdir-early-banks-2015-07-20-00
Hello,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Status: Ready

This document describes the Interface to the Routing System (I2RS) problem
statement, expanding upon the requirements (ostensibly, outlined in the
architecture document). The premise is that there is a need for a quick and
dynamic method of understanding and if needed, tweaking, the running routing
state as required. This draft posits that existing mechanisms do not meet this
need; they are either piecemeal and/or proprietary, and do not meet the
complete set of requirements.

As a reader, I found the document straightforward and easy to read. Indeed, the
diagram that outlines what is in scope and what isn't left me wanting more
ideas on what is clearly marked as out of scope :) I did have one question
though. In section 5, there's a requirement for "high-throughput" - which seems
a bit of a misnomer, as the section describes a need for a high number of
transactions or operations per second. An example number in the draft is
10,000/second, with the ability to change many individual subscriber routes
simultaneously. I wonder at what point the operator runs into some number of
transactions/second that constitutes an unintended denial of service attack on
the agent side; was this considered as a possibility, intentional or not? This
question isn't a gating question.

Best,

Sarah