Hi Nabil, Thank you very much for doing this very useful review. I have posted draft-ietf-i2rs-problem-statement-07 and the differences can be seen at: https://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-problem-statement-06&url2=draft-ietf-i2rs-problem-statement-07&difftype=--hwdiff
I did take a number of your wording changes in. If you can take a look at the updated draft, that would be useful. Thanks, Alia On Mon, Jun 15, 2015 at 7:51 PM, Susan Hares <[email protected]> wrote: > Nabil: > > > > Thank you for this review. The I2RS chairs appreciate the careful > review. I think we are aligned with you that we want a fresh-updated > draft-ietf-i2rs-problem-statement. Alia Atlas (one of the co-author) and I > will chat within a day or so and get back to you on the nits. > > > > Sue > > > > *From:* Bitar, Nabil N [mailto:[email protected]] > *Sent:* Monday, June 15, 2015 7:38 PM > *To:* [email protected]; [email protected] > *Cc:* [email protected]; BRUNGARD, DEBORAH A; Jonathan Hardwick; > [email protected] > *Subject:* [RTG-DIR] Routing directorate review of > draft-ietf-i2rs-problem-statement > > > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, please > see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-i2rs-problem-statement-06.txt > > Reviewer: Nabil Bitar > Review Date: 6/14/2015 > IETF LC End Date: Unknown > Intended Status: Informational > > *Summary:* > > I have some minor concerns about this document that I think should be > resolved before publication. The document has nits that should also be > considered prior to publication. > > *Comments:* > > This document is intended to describe the problem that i2rs needs to > address. The document readability can be improved by:: > > 1. starting with the abstract, clearly and progressively stating what > i2rs is, the driver for the problem to be addressed, and the > objective/problem to be solved. Comments that address this issue are > aprovided. > > I took several of thse comments in. > > 1. > 2. Clearly identifying early in the document where currently solutions > that seem to be addressing the problem fail. This is a key component of the > problem statement. This is currently left ambiguous to the reader untiil > the appendix. For instance, the document may refer to the appendix early > on, pointing the reader to gaps in existing interfaces for managing routing > information compared to the needs. > > Please check if this is adequately addressed. There's a fine line between talking about new functionality that is useful and bashing existing and highly successful solutions. > > 1. > 2. Defining or referring to the definition of terminology used in the > document > > I added "*This document uses terminology defined in * *[I-D.ietf-i2rs-architecture]* in Section 2. > > 1. > > *Major Issues:* > > No major issues found > > *Minor Issues:* > > 1- Abstract: I suggest the addition of the following at the beginning of > the first paragraph: > > Traditionally, routing systems have implemented routing and signaling > (e.g., multiprotcol label switch) protocols to control traffic forwarding > in a network. Route computation has been controlled by relatively static > policies that define link cost, route cost or import and export routing > policies. With the advent of highly dynamic data center networking, > on-demand WAN services, dynamic policy-driven traffic steering and service > chaining, the need for real-time security threat responsiveness via traffic > control, and the software defined networking paradigm, the need has > emerged to more dynamically manage and program routing systems in order to > control routing information and traffic paths, and to extract network > topology information and traffic statistics, among others, from routing > systems. As modern networks continue to grow …… (the rest of the first > paragraph in the abstract. > > 2-Abstract: second paragraph first sentence, suggest the following > modification: > > In order to enable network applications to have access to and control over > information in the internet’s routing system, we need a publicly documented > interface specification. —> In order to enable network applications to > access and control information in a routing system uniformly across > implementations, we need a standard specification for the interface to the > routing system that enables such control. > > > > 3- Abstract: Second paragraph, second sentence: > > The interface needs to support real-time, asynchronous interactions using > data models and encodings that are efficient and potentially different from > those available today. —> The interface needs to support real-time, > asynchronous interactions using efficient data models and encodings that > could be potentially different from those already defined. > > > > 4- Introduction, first sentence second line: > > Flexible and dynamic control increases. —> flexible, scalable and dynamic > control increases. > > > > 5- Introduction, last paragraph, second sentence on page 3: > > > > This is meant to refer to an executable program of some sort that has > access to a network, such as IP or MPLS network —> This is meant to refer > to an executable program that has direct or indirect access to a network, > such as an IP or MPLS network, in order to control routing behavior or > extract information. > > > > 6- Section 2, 1st paragraph 1st sentence and 2nd sentence:: > > > > "Managing a network of production devices running a variety of routing > protocols involves interactions between multiple components within a > device. Some of those components are virtual while some are physical; it > may be desirable for many, or even all of these components to be made > available to be managed and manipulated by applications, given that > appropriate access, authentication and policy hurdles have been crossed." > > > > I am not sure what is the significance of virtual or physical within a > device. > > > > Change to: > > > > Managing a network of systems running a variety of routing protocols > and/or providing one or more additional service (e.g., forwarding, > classification and policing, firewalling) involves interactions among > multiple components within these systems. Some of these systems or system > components may be virtualized, co-locqted within the same physical system > or distributed. In all cases, it is desirable to enable network > applications to manage and control the services provided by many, if not > all, of these components, subject to authenticated and authorized access > and policies. > > > > 7- section 2, middle of the first paragraph: > > “the management of of only some of these component requires (note missing > “s” in original text) standardization as others have already been > standardized.” > > > > While I understand the intention, this is an ambiguous general statement > that begs the question which components require standardization and which > ones do not. > > > > I suggest the following wording: > > > > The i2rs working group must identify the components that need to be > managed via i2rs and require new a standardization effort. > > > > 7- section 2, when talking about the I2RS model, I suggest that you refer > to the terminology defined in the i2rs architecture document and define the > new terminology otherwise. Specifically, what is anI2RS client, I2RS agent, > etc. > > > > 8- section 2, the sentence before last in the first paragraph: > > > > “The I2RS client is used and controlled by one or more network > applications; they may be co-located or the I2RS client might be part of a > separate application, such as orchestration or controller.” > > > > This seems to imply that an orchestrator or controller is an application, > while each could be composed of one or more applications. In addition, what > a controller or orchestrator is not defined in this document either > directly or by reference. I suggest the following: > > > > The I2RS client could be integrated in a network application, or > controlled and used by by one or more separate network applications. For > instance, an I2RS client could be provided by a network controller or a > network orchestration system that provides a non-I2RS interface to network > applications, and an I2rS interface to I2RS agents on the system being > managed. > > > > 9- Section 2 Figure 1, suggest to include in words what is within i2rs > scope in the figure in order to make it easirer for the reader. I suggest > the following: > > > > As depicted in Figure 1, the I2RS client and I2RS agent in a routing > system are objects within the I2RS scope. The i2RS protocol or set of > protocols to be defined/and or identified extend between the I2RS client > and I2RS agent. All other objects and interfaces in Figure 1 are outside > the I2RS scope. > > > > 10- section 3, page 5, last sentence of the first paragraph: > > “In addition, by having I2RS focus initially on interfaces to the RIB > layer (e.g., RIBm LIB, multicast RIB, policy-based routing), the ability to > use routing indirection allows flexibility and functionality that can’t be > easily obtained at the forwarding layer.” > > > > I am not sure what is the point you are trying to make in the last phrase > in this sentence pertaining to the forwarding plane. Can you please > explain? I don’t see it as a valid statement and therefore why it is needed. > > > > 11- section 3, third paragraph: > > > > “.. , there is need to configure the various routing and signaling > protocols with differing dynamic state based upon application-level policy > decisions.” > > > > You are not configuring routing and signaling protocols' dynamic states, > you are configuring policies and values for parameters that effect route > computation/decision or routing information that goes into the RIB. If you > agree, can you make th corresponding update. > > > > 12- section 3, third paragraph > > > > “The range desired is not available via MIB modules at the present”. > > > > Can you clarify what range you are referring to and subsequently any > reference to where it is deemed that current MIBS do not not support the > need. I am not sure though there is need to refer to current MIBs. > > > > 13- section 4 page 5, last sentence: > > > > “I2RS provides a framework …” ——> I2RS should provide a framework ….. > > > > 14- section 4, page 6 1st paragraph first sentence. > > > > “.. Still provide only the current active state as seen at the IGP layer > and above.” > > > > What are you defining by above in this context? > > > > 15- Section 4, page 6 3rd paragraph last sentence: > > > > “.. the full range is not” > > > > Can you give an example to illustrate? > > > > “nor has there been successfully deployed the standardized ability to > setup the router to trigger different actions upon an events’ occurrence so > that a rapid reaction can be accomplished” > > > > Wouldn’t FRR for instance be a counter example to this statement? > > > > 16- Section 5, page 7, > > > > “High-Throughput: At a minimum, the I2RS agent and associated router > should be able to handle a considerable …” —> High-Throuput: at a minimum, > within the I2RS scope, the I2RS agent and I2RS client(s) should be able to > handle a considerable … > > > > Multi-Channel: "….. Thus a single TCP session would not be a good match” > > > > This comes across as if you are already that TCP will always be the > transport layer. I suggest the following change: > > > > > > *Nits:* > > 1. Section 8, security considerations: 3rd line, missing “.” after > section 5. > 2. Appendix A, page 9, 4th paragraph 2nd line: “…., and configuration > is The Simple Network management Protocol” —> “….. And configuration is the > simple network management protocol (SNMP)" > > > - Nits are editorial or layout items. They are things that would > ideally be resolved before publication to make the document more readable, > and may be raised now to save the RFC Editor work. > - Usually a reviewer will not be looking for this type of issue, but > may find some in the course of their review. > - Please try to avoid raising esoteric questions of English usage. The > RFC Editor will spot these, and it is not a wise use of time to discuss > these things. > - If you find no nits, please leave this section out. > > > > Thanks, > > Nabil > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
