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

[Alia Atlas <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] 代表
> [e-mail]
> 发送时间: 2015年12月19日 7:06
> 收件人: [e-mail]
> 抄送: [e-mail]
> 主题: 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
> [e-mail]
> 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
>