Re: [RADIR] Last Call on problem statement -01

"John G. Scudder" <jgs@juniper.net> Wed, 03 October 2007 01:23 UTC

Return-path: <radir-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icsxx-00020v-EV; Tue, 02 Oct 2007 21:23:57 -0400
Received: from radir by megatron.ietf.org with local (Exim 4.43) id 1Icsxw-0001yc-52 for radir-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 21:23:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icsxv-0001xA-I1 for radir@ietf.org; Tue, 02 Oct 2007 21:23:55 -0400
Received: from exprod7og60.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icsxp-0002v4-71 for radir@ietf.org; Tue, 02 Oct 2007 21:23:55 -0400
Received: from source ([66.129.224.36]) by exprod7ob60.obsmtp.com ([64.18.6.12]) with SMTP; Tue, 02 Oct 2007 18:17:44 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 18:17:23 -0700
Received: from [172.16.13.200] ([172.16.13.200]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l931HNn19255; Tue, 2 Oct 2007 18:17:23 -0700 (PDT) (envelope-from jgs@juniper.net)
In-Reply-To: <200709251340.l8PDeaeg002770@cichlid.raleigh.ibm.com>
References: <200709251340.l8PDeaeg002770@cichlid.raleigh.ibm.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/mixed; boundary="Apple-Mail-8-466152969"
Message-Id: <26D8DC6D-A76A-43BE-AD48-2068D3E03384@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
Subject: Re: [RADIR] Last Call on problem statement -01
Date: Tue, 02 Oct 2007 21:17:14 -0400
To: Thomas Narten <narten@us.ibm.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 03 Oct 2007 01:17:23.0837 (UTC) FILETIME=[273A8AD0:01C8055B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Cc: radir@ietf.org
X-BeenThere: radir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Directorate <radir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/radir>, <mailto:radir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/radir>
List-Post: <mailto:radir@ietf.org>
List-Help: <mailto:radir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/radir>, <mailto:radir-request@ietf.org?subject=subscribe>
Errors-To: radir-bounces@ietf.org

Thomas,

On Sep 25, 2007, at 9:40 AM, Thomas Narten wrote:
> Here is the current version of the problem statement.
>
> I think it's ready for reposting and then trying to broaden the
> number/type of reviews we get. I'll wait for a few "ship it" comments
> before posting, to give folk a chance to reread the entire document.

Here are my comments.

1. In this definition:

Control Plane Cost:  The overall cost associated with operating the
       Control Plane.  The cost consists of capital costs (for  
hardware),
       bandwidth costs (for the control plane signalling) and any other
       operational cost associated with operating and maintaining the
       control plane.  In the present Internet, the primary current cost
       concern is on the capital hardware."

The final sentence, "In the present Internet, the primary current  
cost concern is on the capital hardware", caught me by surprise until  
I reread it focusing on the context of control plane cost.  Even  
then, I'm not sure everyone would agree that capital hardware is  
their greatest concern when it comes to control plane.  It would  
probably not be hard to create a lively conversation in various  
forums by putting up the strawman that the opex associated with the  
current Internet control plane is insignificant.

I would suggest simply deleting the sentence.

2. Replace "more specific" with "more-specific" throughout except of  
course if it's not being used to mean "more specific route", or where  
it's fully written out as such.  (Also if grepping note that it's  
broken across lines in some cases.)

3. Point 6 of the summary section seems to be redundant with point  
1.  Delete it?

4. Speaking of section 6, can someone remind me why we didn't think  
"provides end-to-end convergence/restoration of service at least  
comparable to that provided by the current architecture" was worth  
including?

5. I made a few trivial proofreading edits to the document and have  
attached a diff.

Thanks,

--John
_______________________________________________
RADIR mailing list
RADIR@ietf.org
https://www1.ietf.org/mailman/listinfo/radir