Re: [RAM] First cut at routing & addressing problem statement
"John G. Scudder" <jgs@bgp.nu> Tue, 31 July 2007 18:35 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwYu-0003v9-BZ; Tue, 31 Jul 2007 14:35:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwYt-0003pL-6Q for ram@iab.org; Tue, 31 Jul 2007 14:35:15 -0400
Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFwYr-0001gS-Oy for ram@iab.org; Tue, 31 Jul 2007 14:35:15 -0400
Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 0897B53E0F8; Tue, 31 Jul 2007 14:35:13 -0400 (EDT)
X-Virus-Scanned: amavisd-new at bgp.nu
Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id mOkp1g3K-FNI; Tue, 31 Jul 2007 14:35:04 -0400 (EDT)
Received: from [172.16.13.200] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 0526753E0EA; Tue, 31 Jul 2007 14:35:03 -0400 (EDT)
In-Reply-To: <901157.22509.qm@web58708.mail.re1.yahoo.com>
References: <901157.22509.qm@web58708.mail.re1.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <CF6F732A-9EFB-431F-B566-8776B568BD76@bgp.nu>
Content-Transfer-Encoding: 7bit
From: "John G. Scudder" <jgs@bgp.nu>
Subject: Re: [RAM] First cut at routing & addressing problem statement
Date: Tue, 31 Jul 2007 14:35:00 -0400
To: Peter Sherbin <pesherb@yahoo.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org
Peter, Thanks for your comments. With regard to statement 1, we discussed whether targeted numbers might be worth including but decided in the end not to do so for several reasons. For one thing, it's an invitation for contentious argument about exactly what the numbers should be -- which would seem to be a rathole. For another, the supportable values are certainly a moving target, based on the state of the art at any given time. With regard to statement 4, I personally think it's OK as written. Surely a proposal which can allow switching with no configuration changes also optimally fulfills "minimizing configuration changes". Seems like flat-out forbidding any slightest configuration change would be going too far, though I think it's clear that forced site config changes are undesirable. With regard to statement 5, with what other statements do you think it's redundant? Note that statement 5 focuses on the alignment of cost and benefit. Regards, --John On Jul 27, 2007, at 1:50 PM, Peter Sherbin wrote: > Enjoined reading the statement. Re the "flatter" Internet in 5.1. > since around 2000 > seemingly there is a trend in changing upstream transit contracts > to peering > arrangements. By Q1 2007 in the observed example over 80% of > traffic is routed via > peers. > > Statement 1. Would it be beneficial to define the targeted number > of individual > prefixes in DFZ, specify the update rate and then architecture > towards those > numbers? E.g. assume 1 AS per each 10,000 sq km of Earth's surface > and 9 routes per > AS. It gives about 450K as the maximum number of DFZ entries > providing an idea of > the router required processing power. > > Statement 4. Make it more rigid "Allows end sites to switch > providers without > configuration changes to internal end site devices". > > Statement 5. seems redundant > > Thanks, > > Peter > > > > --- Thomas Narten <narten@us.ibm.com> wrote: > >> The Routing & Addressing directorate has been working on a strawman >> problem statement since Prague. I just submitted our first cut as an >> Internet Draft and it's available at: >> >> http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem- >> statement-00.txt >> >> We would welcome comments on the document. In particular: >> >> - Do folk agree with the problem statement as written, or are we >> missing something fairly fundamental? >> >> - Are there other pressures on the routing system that we have not >> listed or described completely? >> >> - We intentionally did not include improving mobility as a core >> "problem", as explained in the document. (That doesn't mean we >> don't recognize that some of the solutions under discussion may >> also be applicable to mobility scenarios. Rather, we tend to see >> improved mobility as a possible benefit of certain classes of >> solutions.) >> >> - Are there other views of what folk perceive the core routing and >> addressing problem to be? >> >> Thomas >> >> _______________________________________________ >> RAM mailing list >> RAM@iab.org >> https://www1.ietf.org/mailman/listinfo/ram >> > > > > > ______________________________________________________________________ > ______________ > Get the free Yahoo! toolbar and rest assured with the added > security of spyware protection. > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] rrg presentation slides online? Ved Kafle
- [RAM] First cut at routing & addressing problem s… Thomas Narten
- Re: [RAM] First cut at routing & addressing probl… Ricardo V. Oliveira
- Re: [RAM] First cut at routing & addressing probl… Peter Sherbin
- Re: [RAM] First cut at routing & addressing probl… Jason Schiller
- Re: [RAM] First cut at routing & addressing probl… Robin Whittle
- Re: [RAM] First cut at routing & addressing probl… Robin Whittle
- Re: [RAM] First cut at routing & addressing probl… John G. Scudder
- Re: [RAM] First cut at routing & addressing probl… Thomas Narten
- Re: [RAM] First cut at routing & addressing probl… JFC Morfin
- Re: [RAM] First cut at routing & addressing probl… JFC Morfin
- Re: [RAM] First cut at routing & addressing probl… Peter Sherbin
- Re: [RAM] First cut at routing & addressing probl… Robin Whittle
- Re: [RAM] First cut at routing & addressing probl… Thomas Narten
- Re: [RAM] First cut at routing & addressing probl… JFC Morfin
- Re: [RAM] First cut at routing & addressing probl… Brian E Carpenter
- Re: [RAM] First cut at routing & addressing probl… JFC Morfin
- Re: [RAM] First cut at routing & addressing probl… Eliot Lear
- [RAM] draft-sherbin-eia-00.txt Peter Sherbin