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

 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