Subject: [i2rs] Barry Leiba's comments on proposed I2RS charter

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 Jan 2013 14:48:24 -0000

Hi,

Barry has entered the following comments on the proposed charter.

Your comments please.

Adrian

===

Block (2012-12-27) 

The second paragraph says this:

   I2RS facilitates real-time or event driven interaction with the
   routing system through a collection of control or management
   interfaces. These allow information, policies, and operational
   parameters to be injected into and retrieved (as read or by
   notification) from the routing system while retaining data
   consistency and coherency across the routers and routing
   infrastructure, and among multiple interactions with the routing
   system.

Nowhere that I can see does it give me any idea what the target of these
interfaces is: what is it that you want having interaction with the routing
system?  What is it that will inject information, policies, and operational
parameters, that can't do so now?

Comment (2012-12-27) 

Especially because charters, including this one, don't have the sorts of
citations and references that we have in RFCs, it would be helpful to expand
"RIB" and "FIB" (and, for completeness, "BGP") on first use.  I know that
routing people know those terms cold... but some of us don't (Wikipedia taught
be that they're "Routing Information Base" and "Forwarding Information Base",
so I'm now better informed).

---

From: Russ White <[email-masked]>
Date: Sun, 06 Jan 2013 09:53:11 -0500

> parameters, that can't do so now?

I think defining this would be out of scope... ??

We're not trying to define what it is that wants to interact with the
control plane in this way, only to provide an interface for any such
processes. The use cases point us to examples where these interactions
are defined without identifying what the off-board processes actually
look like.

Or maybe I misunderstand the comment?

> so I'm now better informed).

I would agree with this one.

:-)

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 6 Jan 2013 21:59:20 +0100

I totally agree with Barry Leiba's comment. I mentioned before that
charter SHOULD be clear to all readers, as he mentioned not only
routing expert participants.

It will be helpful to make references as he mentioned, as I think the
documents in the charter already a good reference but no objection to
add others. However, I think giving work-examples and referencing
initial I2RS work in progress will be a good start for people to know
what it is all about. If the RIB and FIB is not described abreviation
in the charter it SHOULD do, but it can be defined more in the
documents terminology.

Thanks for comments,

AB

On 1/6/13, Adrian Farrel <[email-masked]> wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 7 Jan 2013 04:03:30 +0100

> system?

I want a protocol/user or multi protocols having that relation with
RSs. Why not having interaction? IMO, we let the Use-Case for each
document to answer, and others to answer why not.

> What is it that will inject information, policies, and operational

Q) Does the RS not need external information?, and does the RS can do
every thing for users without help?
IF  the Q answer is yes, THEN , we can *do so now* and lets close I2RS,
ELSE, we need I2RS protocol(s).

Abdussalam Baryun
University of Glamorgan, UK

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Jan 2013 22:06:56 -0000

Hi Barry,

The discussion of your review comments went on on the I2RS list without fully
copying you on the responses. Let me try to summarise where we got to and add
some detail myself.

> parameters, that can't do so now?

I having a little difficulty parsing your questions, so let me give some
broad-scope answers.

The object of the interfaces is the routing system. I think this is clear in the
second paragraph of the draft charter.

The purpose of the interactions at the interfaces are, I think, captured in the
second sentence of the second paragraph and (perhaps more importantly) in the
use cases.

The subject of the interfaces is some lump of stuff that decides to poke the
routing system. In the architecture (I-D) the subject end of the interface is
called the I2RS Client and serves one or more "applications". We got a bit hung
up about what constitutes an application: is it, for example, a P2P streaming
application, or is it a tool that is responsible for shaping the network? In the
end, the answer appeared to be "yes".

Now, on the list it was suggested that this is and should be deliberately out of
scope...

| We're not trying to define what it is that wants to interact with the
| control plane in this way, only to provide an interface for any such
| processes. The use cases point us to examples where these interactions
| are defined without identifying what the off-board processes actually
| look like.

That leaves us with your last part of the question which I will invert to read:
what can be done today? The problem here is that there is a feeling that the
existing standardised protocols and encoding languages are missing features to
provide the necessary functions. There is a lot of debate on this, which is why
it is necessary to do requirements work. Additionally, we need information
models for the things that are to be injected/retrieved.

Of course, it is likely that in a number of vendors' router quite a few of the
things can be injected or retrieved using CLI, proprietary protocols,
proprietary extensions to existing protocols, or proprietary schemas for
existing encoding languages. But that is not a standard solution.

> so I'm now better informed).

OK, we can do that.

Hoping this clears your issues.

Cheers,
Adrian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Jan 2013 18:40:14 -0500

Hi, Adrian (and i2rs gang), and thanks for the response.

> The subject of the interfaces

Yes, that's what I was asking about.

> is some lump of stuff that decides to poke the

I would feel happier if some sense of that could be in the charter
(but see below).  In general, when we propose creating an interface to
X, we have some idea of who or what we want to be using that interface
(the subject, as you say).  I understand the use cases document will
go into that in much more detail, but I'd be happier if the charter
said *something* about it.  I don't know whether you're talking about
having a data center's operation & management system using the
interface, having a web server that sits in a customer's office using
the interface, or having a web browser that runs in an end-user's iPad
using the interface.

If the answer really is, "Yes, all of those," then a few words in the
charter should be possible, no?  "This interface is expected to be
used by systems as diverse as a data center's operation/management
system, a web server, and a peer-to-peer streaming application.  The
working group will provide details of these and other applications as
it develops its use cases."  Perhaps something like that could be
added to the paragraph that begins "I2RS facilitates real-time or
event driven interaction with the routing system"?

> | are defined without identifying what the off-board processes actually

I won't block this further, but I really think that leaving out *all*
explanation of this makes for a charter that will be hard for people
who are not already familiar with what you're doing to read and
understand.  The point here isn't to rein in the use cases (I'm not
asking for that and wouldn't want that), but to make things clear to
someone reading the charter.

I'll clear the block and put what remains into a comment.

Barry

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 10 Jan 2013 11:18:04 -0000

It's a bit vague, but how about we added...

"It is envisioned that users of the I2RS interfaces will be management
applications, network controllers, and user applications that make specific
demands on the network."

IMHO this covers all bases, but in doing so doesn't say much.

OTOH, if it helps to bring sunshine to an otherwise gray world...

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry
> Leiba
> Sent: 09 January 2013 23:40
> To: Adrian Farrel
> Cc: IESG; [email-masked]
> Subject: Re: Barry Leiba's comments on proposed I2RS charter
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Jan 2013 08:18:04 -0500

> applications, network controllers, and user applications that make specific

Yeh, fine with me; carry on.

Barry

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 10 Jan 2013 14:26:41 +0100

>> applications, network controllers, and user applications that make

Yes that will be best and clear,

AB