[RAM] Different approaches for different protocols
RJ Atkinson <rja@extremenetworks.com> Wed, 19 December 2007 14:59 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 1J50O0-0005lQ-VB; Wed, 19 Dec 2007 09:59:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Nz-0005jd-70 for ram@iab.org; Wed, 19 Dec 2007 09:59:03 -0500
Received: from eastrmmtao107.cox.net ([68.230.240.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50Ny-0007aD-Pz for ram@iab.org; Wed, 19 Dec 2007 09:59:03 -0500
Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071219145901.FMUA8815.eastrmmtao107.cox.net@eastrmimpo01.cox.net> for <ram@iab.org>; Wed, 19 Dec 2007 09:59:01 -0500
Received: from [10.30.20.71] ([68.10.115.26]) by eastrmimpo01.cox.net with bizsmtp id SeyH1Y0080aEP1Q0000000; Wed, 19 Dec 2007 09:58:17 -0500
Message-Id: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com>
From: RJ Atkinson <rja@extremenetworks.com>
To: ram@iab.org
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 19 Dec 2007 09:59:01 -0500
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [RAM] Different approaches for different protocols
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
There seem to be one or two assumptions implicit in most of the notes I see archived here and elsewhere on the R&A topic. A) We only really need to worry about a solution that works for the currently deployed IPv4 network, since that is the only network segment that is in near-term danger of hitting IDR scaling limits. I think the above assumption would be incorrect, since IPv6 has the same architectural limitations as IPv4. Both use the same BGP-based methods for site-multihoming, which is the main driver of RIB/FIB entropy at present according to various papers in the published literature. B) We must use the same solution for both IPv4 and IPv6, since it is the same fundamental problem. I think that assumption is also incorrect, since IPv6 does have many more bits to work with than IPv4. Purely as an example, a solution that is part of the 8+8 family is quite straight-forward to implement/deploy with IPv6 because the IPv6 address already is conceptually split into two separate Routing Prefix and Interface ID components. However, for IPv4, an 8+8-like solution is more challenging. One might use the existing IPv4 "address" as a locator/routing prefix and then add separate Identifiers as an IPv4 option (workable in theory, but not in reality because routers would roll over and whimper like a puppy when trying to send every IPv4 packet via slow-path CPU forwarding). So I would suggest that folks think about IPv4 and IPv6 solution approaches separately. For example, while one might want one of the existing proposal for IPv4 (partly for expediency and partly because IPv4 has more constraints), one might well want a different more architecturally fundamental change for IPv6 (partly because the protocol is more flexible due to extra bits in the header and partly because we have more time to study, prototype, and design a more elegant solution). Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] Different approaches for different protocols RJ Atkinson
- Re: [RAM] Different approaches for different prot… Iljitsch van Beijnum
- Re: [RAM] Different approaches for different prot… Tony Li
- RE: [RAM] Different approaches for different prot… Templin, Fred L
- Re: [RAM] Different approaches for different prot… Scott Brim
- Re: [RAM] Different approaches for different prot… Dino Farinacci
- Re: [RAM] Different approaches for different prot… Dino Farinacci
- Re: [RAM] Different approaches for different prot… RJ Atkinson
- Re: [RAM] Different approaches for different prot… Tony Li
- Re: [RAM] Different approaches for different prot… Lixia Zhang
- Re: [RAM] Different approaches for different prot… Dino Farinacci
- Re: [RAM] Different approaches for different prot… Noel Chiappa