Subject: Re: [i2rs] working group last call: draft-atlas-i2rs-problem-statement

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Jun 2014 16:42:40 +0200

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
?

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.

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.

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

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 :)

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 ?

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.

Thx,
R.

On Fri, May 16, 2014 at 11:15 PM, Edward Crabbe <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 26 Jun 2014 17:11:41 -0400

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.

> 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.

> for a given information and compiles the product itself. My question

[Alia] I think it is the former

> distributed systems. While former is much easier the latter may help

[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.

> draft-ietf-idr-ls-distribution

[Alia] Absolutely - thanks for the catch!

> 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.

> redesign by some vendors which today may not have all opaque info

[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.

> 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