RE: draft-ietf-ipv6-ula-central-02.txt

Roger Jorgensen <rogerj@jorgensen.no> Wed, 11 July 2007 18:33 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gzz-0001nG-GS; Wed, 11 Jul 2007 14:33:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gzy-0001n5-Fs for ipv6@ietf.org; Wed, 11 Jul 2007 14:33:14 -0400
Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8gzt-0002PO-Uv for ipv6@ietf.org; Wed, 11 Jul 2007 14:33:14 -0400
Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l6BIX7wm014699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 20:33:07 +0200 (CEST)
Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.13.6) with ESMTP id l6BIX6CV027679; Wed, 11 Jul 2007 20:33:06 +0200
Date: Wed, 11 Jul 2007 20:33:06 +0200
From: Roger Jorgensen <rogerj@jorgensen.no>
X-X-Sender: rogerj@chandra.student.uit.no
To: Tony Hain <alh-ietf@tndh.net>
In-Reply-To: <072c01c7c3dd$122b6110$36822330$@net>
Message-ID: <Pine.LNX.4.64.0707112026200.9923@chandra.student.uit.no>
References: <200706251556.l5PFu6Qa057410@mail.reprise.com><078201c7bdb0$503f2dc0$543816ac@atlanta.polycom.com><94065E4E-7A57-46AC-8A13-D7591C26EA13@apple.com><Pine.LNX.4.64.0707101337220.9923@chandra.student.uit.no><FEB5791F-8495-4905-8D6C-D454F46FD976@apple.com><22851.1184090216@sa.vix.com><B29043A9-6165-47FB-B83A-0A5272A0C451@apple.com> <Pine.LNX.4.64.0707111133400.9923@chandra.student.uit.no> <D03E4899F2FB3D4C8464E8C76B3B68B0AA2CAA@E03MVC4-UKBR.domain1.systemhost.net> <28681.1184163817@sa.vix.com> <072c01c7c3dd$122b6110$36822330$@net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: : ok
X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ipv6@ietf.org
Subject: RE: draft-ietf-ipv6-ula-central-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

On Wed, 11 Jul 2007, Tony Hain wrote:
> I have a few points on Paul's draft:
<snip>
> Major complaint -  aggregation
> 	There needs to be at least a modest capability to aggregate. I
> understand the aversion to having these show up in the DFZ, but if 5.1 were
> really true that would not be an issue. The use case that needs to be
> supported is for internal aggregation of private peering clusters. Global
> organizations have many external relationships, but typically have them
> clustered in small groupings for logistics reasons. At the same time they
> don't necessarily want to carry the explicit routes for every organization
> throughout their internal network. If the ULA-C/G space has some modest
> aggregation  like sparse allocation of the RIR num block to allow clustering
> subsequent block to the same RIR and a suggestion for E-W-N-S regional
> management within the RIR space, then it would be possible to aggregate the
> internal routes to these private peering clusters.

IF we assume and prepare the ground for aggregation, would that just make 
it easier in the future for this type of addresses being leaked?

Anyway, 3.1 mention:
" Local Num  Identifiers assigned by an RIR (or LIR) for each /48 as
               allocated to an end site or user.  It is expected that
               allocations by an RIR to an LIR will be in blocks of 1000
               consecutive Local Nums, to amortize administrative workload."

which again give us some sort of aggregation... is this something we want? 
(althought it would fit us, where I work, perfectly since we would get 
almost all the space we need quite easy:-)

But then again 5.5 say it is recommanded to not allocate aligned blocks...

maybe clean up the wording on those part a bit?

<snip>

-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
roger@jorgensen.no           | - IPv6 is The Key!
-------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------