Early Review of draft-ietf-i2rs-problem-statement-06
review-ietf-i2rs-problem-statement-06-rtgdir-early-bitar-2015-06-16-00

Request Review of draft-ietf-i2rs-problem-statement
Requested rev. no specific revision (document currently at 11)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-06-16
Requested 2015-05-20
Authors Alia Atlas, Thomas Nadeau, David Ward
Draft last updated 2015-06-16
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 Nabil Bitar
State Completed
Review review-ietf-i2rs-problem-statement-06-rtgdir-early-bitar-2015-06-16
Reviewed rev. 06 (document currently at 11)
Review result Has Issues
Review completed: 2015-06-16

Review
review-ietf-i2rs-problem-statement-06-rtgdir-early-bitar-2015-06-16

 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::

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.

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.  

Defining or referring to the definition of terminology used in the document

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:

Section 8, security considerations: 3rd line, missing “.” after section 5.

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