Re: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-08.txt

Alia:
Thanks for the update and addressing my comments in the new version (-09), I have updated shepherd report accordingly.

-Qin
发件人: Alia Atlas [mailto:akatlas@gmail.com]
发送时间: 2016年1月16日 2:14
收件人: Qin Wu
抄送: i2rs@ietf.org; db3546@att.com; Jeffrey Haas; Susan Hares
主题: Re: I-D Action: draft-ietf-i2rs-problem-statement-08.txt

Hi Qin,

Thank you very much for the review.  My apologies for the delay in responding; I've been sick.

On Mon, Jan 4, 2016 at 10:40 PM, Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote:
Hi, Alia:
Thanks for the update to address Nabil comments and AD's comments.
I have re-read this draft, I agree with you that section 5 and section 4 have great value and provide a clear goal and good guidance for all the I2RS related work. I think this draft is ready for publication.
Here are a few editorial comments and suggestions for your consideration.
1. Section2, paragraph 5:
s/with in/within

fixed

2. Section 2,Figure 1:
In the figure 1, “<== I2RS protocol” is used to indicate I2RS protocol is used on the interface between I2RS client and I2RS agent.
But In the legend following the figure 1, there is no legend description for “<==”.

added a description for clarity

3.Section 2, paragraph 7:
Is this component(i.e., subscription and configuration) a kind of data source for measurement data or event data? Why configuration is specially needed for this component rather than other component? How this logical component is used to collect measurement data, statistics, how event is collected?

I2RS isn't trying to define the internal components of a router.  It's convenient for a picture and for discussion to talk about "subscription and configuration
for dynamic measurements/events" but how that logical component is implemented will vastly vary based on internal device architecture.  It could be distributed or centralized.

I see your questions, but really don't see an appropriate answer to put in a problem-statement.   Configuration might, for example, be for IPFIX streams or to indicate what events or data should be measured.

I know the subscription and configuration component is not in the scope of I2RS? However I am curious to know whether subscription and configuration also used for providing authentication and authorization or security purpose?

IMHO, not for the authentication and authorization needed by I2RS.   Could one get a subscribe to information that would be related to security purposes?  I imagine so, but that will depend on what models are defined and use-cases considered.

4. Section 3, paragraph 1:
What is the difference between Next hop indirection and routing indirection?

Next-hop indirection is described well in the RIB info-model.  Basically, one next-hop might point to another so that when the second changes, the first is also impacted.   Routing indirection can use next-hop indirection as a mechanism;  for instance, a BGP route might use an IGP route to determine its next-hops - and thus the BGP route will change based on how the IGP changes.

I don't see anything specific to change in the draft.

5. Section 4, last paragraph:
Not sure policy decision is made by application? If my understanding is correct, Application should describe goal or objective, the policy decision is made by I2RS client, the I2RS agent enforce policy in the routing system.

This depends on what you are thinking of as an application and what as an I2RS client.  I think of the I2RS client as handling the protocol and communications to the appropriate I2RS agents.  I do not see the I2RS client as doing policy decisions.  It is possible that there are multiple layers in the application - where the higher layer are setting the goal or object and the lower layer is translating those into policy.   Regardless, again - I don't see any changes to be made.

6. Section 5, bullet 4:
/”i.e.:”/”i.e.,”

ok - fixed

7. Section 5, bullet 4:
If my understanding is correct, Duplex means bidirectional communication between I2RS agent and I2RS client, however when I read the second sentence and the third sentence in this paragraph, I feel a little bit confused,
For the second sentence, yes, operation and acknowledgements can be sent by both parties, however I am not sure the failure or event can be sent by the application or I2RS client to I2RS agent embedded in the router.

That would depend upon the particular model being used.

For the third sentence, why we use negative sentence? Do we mean both pull model and push should be supported? What is the pure pull model? can pull model be used by router to pull response from application?

The sentence is "The I2RS is not a pure pull-model where only the application queries to pull responses."
I feel like that clearly defines what a pure pull-model is.  I2RS should support a push model where the agent can push events to the
client.  I2RS should also support the client querying the agent - as in a pull model.

I don't see any changes to be made based upon this discussion.

Thanks again for the review,
Alia

-Qin
-----邮件原件-----
发件人: I-D-Announce [mailto:i-d-announce-bounces@ietf.org<mailto:i-d-announce-bounces@ietf.org>] 代表 internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
发送时间: 2015年12月19日 7:06
收件人: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
抄送: i2rs@ietf.org<mailto:i2rs@ietf.org>
主题: I-D Action: draft-ietf-i2rs-problem-statement-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Interface to the Routing System Working Group of the IETF.

        Title           : Interface to the Routing System Problem Statement
        Authors         : Alia Atlas
                          Thomas D. Nadeau
                          Dave Ward
        Filename        : draft-ietf-i2rs-problem-statement-08.txt
        Pages           : 11
        Date            : 2015-12-18

Abstract:
   Traditionally, routing systems have implemented routing and signaling
   (e.g.  MPLS) 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 a paradigm of separating policy-based decision-
   making from the router itself, 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, traffic statistics, and other network analytics from
   routing systems.

   This document proposes meeting this need via an Interface to the
   Routing System (I2RS).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-problem-statement-08

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt