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 <[email protected]> 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:[email protected]] 代表 > [email protected] > 发送时间: 2015年12月19日 7:06 > 收件人: [email protected] > 抄送: [email protected] > 主题: 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
