Re: [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement

[Alia Atlas <[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
> *Sent:* Monday, June 15, 2015 7:38 PM
> *To:* [e-mail]; [e-mail]
> *Cc:* [e-mail]; BRUNGARD, DEBORAH A; Jonathan Hardwick;
> [e-mail]
> *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
>
>