Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jul 2012 18:14:48 -0400

I am finding this document quite confusing.

The primary confusion is that the document first says that it is about 
information that can not be manipulated with existing systems, and then 
proceeds to give a list of use cases all of which can be manipulated 
with existing systems at a suitable degree of abstraction.

As a lesser confusion, the document says that "streaming" is important, 
but then describes "streaming" as "fast, interactive access."  That is 
not streaming.  And depending upon what one means by interactive, plenty 
of systems provide "fest, interactive access."  I realize the document 
later goes on tot talk about speed and frequency of state updates.   But 
that section simply reasserts the earlier terms withotu better 
description or justification.

Yours,
Joel

On 7/30/2012 2:08 PM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title           : Interface to the Routing System Framework
> 	Author(s)       : Alia Atlas
>                            Thomas Nadeau
>                            Dave Ward
> 	Filename        : draft-ward-irs-framework-00.txt
> 	Pages           : 21
> 	Date            : 2012-07-30
>
> Abstract:
>     This document describes a framework for a standard, programmatic
>     interface for full-duplex, streaming state transfer in and out of the
>     Internet's routing system.  It lists the information that might be
>     exchanged over the interface, and describes the uses of an interface
>     to the Internet routing system.
>

---

From: Susan Hares <[email-masked]>
Date: Tue, 31 Jul 2012 01:16:14 +0000

Joel and irs-folks: 

+1 on Joel.

 Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.

In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.  

Therefore, you've skipped even requiring the hard problems. 

Is this just the -00.draft? 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, July 30, 2012 3:15 PM
To: [email-masked]
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Yours,
Joel

>     to the Internet routing system.
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 21:33:10 -0400

Hi Sue,

>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-inte…

[Alia] Can you further clarify, maybe with an example, which aspect
you are thinking of?   Do you mean the ability of an application to
access multiple sub-interfaces?  The interaction of operations
requested by differerent applications?

> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.

[Alia] I'm pretty sure that I avoided the word "transaction" in both
drafts.  That was deliberate.  Of course, we can have a discussion
about whether or not some form of transactions might be desirable.  I
am concerned about their potentially heavy-weight nature.

> Therefore, you've skipped even requiring the hard problems.

[Alia] Can I optimistically pretend that means that the requirements
we do have don't seem too hard?  For the responsiveness and throughput
goals, I've put a stake in the ground to avoid transaction-based
semantics.  Naturally, the hordes can run over that stake, if
necessary.

[Alia] For the interaction between different layers of sub-interfaces,
I've been assuming that we'll define the interactions between the
layers based on how they are generally done.  For instance, perhaps we
standardize the idea of preference value - and then the RIB can pick
the best route based upon those preferences.  For interaction between
different applications, I think there's a mixture of
authorization/authentication to get right plus a good set of events
that an application could register for.

> Is this just the -00.draft?

[Alia] Certainly, I expect that we'll uncover more requirements as we
go along.  As I said, some of this is initially setting parts  out of
scope.

Alia