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 rev. 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
Draft 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 Nabil 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
Review review-ietf-i2rs-problem-statement-06-opsdir-early-banks-2015-07-20
Reviewed rev. 06 (document currently at 11)
Review result Ready
Review completed: 2015-07-20

Review
review-ietf-i2rs-problem-statement-06-opsdir-early-banks-2015-07-20

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