Re: Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard
Tim Chown <tjc@ecs.soton.ac.uk> Wed, 23 November 2005 10:46 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ees9P-0005Ec-Md; Wed, 23 Nov 2005 05:46:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ees9N-0005Di-BO for ietf@megatron.ietf.org; Wed, 23 Nov 2005 05:46:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11742 for <ietf@ietf.org>; Wed, 23 Nov 2005 05:46:14 -0500 (EST)
Received: from peewit.ecs.soton.ac.uk ([152.78.68.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EesSC-0000fi-KL for ietf@ietf.org; Wed, 23 Nov 2005 06:06:21 -0500
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id jANAm8W8022419 for <ietf@ietf.org>; Wed, 23 Nov 2005 10:48:10 GMT
Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id jANAkSB18027 for ietf@ietf.org; Wed, 23 Nov 2005 10:46:28 GMT
Date: Wed, 23 Nov 2005 10:46:28 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: ietf@ietf.org
Message-ID: <20051123104628.GJ15133@login.ecs.soton.ac.uk>
Mail-Followup-To: ietf@ietf.org
References: <E1EeaRT-0003Mo-Aw@newodin.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1EeaRT-0003Mo-Aw@newodin.ietf.org>
User-Agent: Mutt/1.4i
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Subject: Re: Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
On Tue, Nov 22, 2005 at 10:52:23AM -0500, The IESG wrote: > The IESG has received a request from the Global Routing Operations WG to > consider the following document: > > - 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and > Aggregation Plan ' > <draft-ietf-grow-rfc1519bis-03.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-06. Hi, I think this is an interesting update. Some minor points that may wish to be considered but feel free to pass over. One is on section 2 - I think the issue is perhaps more the efficiency of usage of IPv4 address space. I know that is tied to rate of consumption, but for many end site admins the impact of CIDR is a lot of paperwork to demonstrate efficient use of allocated (or requested) address space. The rate of growth of the routing tables is perhaps also about the PI vs PA issue. Perhaps these terms could be explained in the text. Another point is the use of private address space in the documentation for example purposes. I know this is hard to avoid, but a statement like "For example, the legacy "class B" network 172.16.0.0, with an implied network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16" seems odd when I normally see 172.16.0.0 and think of it as a /12. A third point is on the negative impacts of CIDR. For example, in squeezing out every bit of the prefix address space, administrators often spend extra time resizing internal (globally addressed) subnets because their provider insists on them maximising the efficiency of their address plans (understandably). Or when a site grows, its ISP offers it a different larger block (requiring renumebring) or non-contiguous ones, adding some internal complexity. I would also suggest that this pressure has led to increased adoption of NAT. I don't see NAT mentioned anywhere in the text - perhaps it is avoided for 'religious' reasons :) I think in contrast to IPv6 address space allocation, in IPv6 we have aggregation from the outset, with a /48 per site (or maybe a /56 for some sites :) and in effect 'infinitely' sized subnets, so the above concerns are not really present for a typical IPv6 deployment. Perhaps again though an aside into IPv6 comparisons with aggregation would be a distraction :) -- Tim/::1 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Last Call: 'Classless Inter-Domain Routing (C… Tim Chown
- Last Call: 'Classless Inter-Domain Routing (CIDR)… Frank Ellermann
- Re: grow: Last Call: 'Classless Inter-Domain Rout… Pekka Savola
- Re: grow: Last Call: 'Classless Inter-Domain Rout… Joe Abley