Hi Robert,

Sorry for the delay and missing these on the first pass!  I really
appreciate that you
took the time to do a careful and thoughtful review.


On Mon, Jun 9, 2014 at 10:42 AM, Robert Raszuk <[email protected]> wrote:

> Regarding draft-ietf-i2rs-problem-statement-01
>
> I have few minor comments:
>
> 1.
> Figure 1 sort of implies that I2RS client to I2RS Agent is always a
> point to point session. Is this intentional or accidental ? I can
> imagine bunch of I2RS clients feeding agends with pieces of required
> information which only putted together makes sense - is this out of
> scope as too complex ? Or is this what is called multi-headed control
> ?
>

[Alia] I've certainly only pictured a point-to-point session.  I don't
expect
that the I2RS agent would "put together pieces" but rather that the I2RS
Clients can send atomic operations.  Together that set might happen to make
up a service, but that wouldn't be realized or dealt with by the I2RS
agent.



> If so It's definition is not that clear. Does "multi-headed"  just
> means number of independent clients feeding in async mode complete
> information chunks or is that I2RS agent can collect pieces of info
> for a given information and compiles the product itself. My question
> is for the latter mode.
>

[Alia] I think it is the former


> 2.
> > In addition to interfaces to the RIB layer,
>
> Are we always talking about global RIB or also RIB on line cards on
> distributed systems. While former is much easier the latter may help
> with scalability issues.
>

[Alia] Hmm, in the problem-statement, I think it can be unspecified.  In
general,
I think about the global RIB - but we do have in the RIB model the idea of
different
routing-instances which apply to only particular interfaces.  So -
depending upon
a particular implementation - feeding routes into a routing-instance with
interfaces
on only a single card might help; I think that's going to be implementation
specific,
but the RIB model should be general enough.



> 3.
> Pls change [I-D.gredler-idr-ls-distribution]) to
> draft-ietf-idr-ls-distribution
>

[Alia] Absolutely - thanks for the catch!


> 4.
> > For applications to have a feedback loop that includes awareness of
> > the relevant traffic, an application must be able to request the
> > measurement and timely, scalable reporting of data."
>
> Frankly I am not sure if I like and support the idea of mixing control
> plane and data plane reporting netflow like data on the same I2RS
> channel/session.
>
> Not questioning the need .. just questioning the approach :)
>

[Alia] Ah - this is why I keep talking and writing about multiple transport
channels.
So - the control can be on one channel and the data-plane reporting can be
on
another agreed upon channel.  IMHO, I want a way to ship data off the
linecards
without it having to travel up to a central point.


> 5.
> > While a few of these (e.g. link up/down) may be available via
> > MIB Notifications today, the full range is not - nor is there the
> > standardized ability to set up the router to trigger different
> > actions upon an event’s occurrence so that a rapid reaction can be
> > accomplished.
>
> So I2RS will also define a router's policy language which will allow
> for setting via I2RS protocol conditional behavior upon specific
> network events ? Will it ever ship complete ? Will it require RIB
> redesign by some vendors which today may not have all opaque info
> there ?
>

[Alia] Well, we may have to have a simple version first - but when there is
a response that wants to happen in a quick fashion, I think that'd help.  I
haven't seen a lot of work on this idea - but I'm happier to have it in the
problem-statement and then we can see.

It's awsome goal and very attractive, but to me it means that this one
> is a bit separate effort which make take much much longer to agreed in
> IETF on then plain I2RS remote control idea.
>

[Alia] Yes.  The idea was more connected when we had time-based operations.
I do think that thinking about the simplest requirements and use-cases here
would help.  The problem-statement might be a bit aspirational for now...

Thanks again,
Alia


>
> Thx,
> R.
>
> On Fri, May 16, 2014 at 11:15 PM, Edward Crabbe <[email protected]> wrote:
> > Hello all;
> >
> > Jeff and I would like to start the two week working group last call for
> > draft-atlas-i2rs-problem-statement.  The document may be found here:
> >
> > http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02
> >
> > The editors and authors are advised to try to resolve as many of the
> > comments as possible (on the mailing list) as they come in, but not to
> > post the new version of the draft until the wglc is closed and the
> > comments are resolved.
> >
> > This working group last call will end on Friday, 5/30/14
> >
> > best,
> >    -ed
> >
> > _______________________________________________
> > i2rs mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/i2rs
> >
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to