Re: [RAM] First cut at routing & addressing problem statement

JFC Morfin <jefsey@jefsey.com> Wed, 01 August 2007 17:38 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 1IGI9P-00038z-Lj; Wed, 01 Aug 2007 13:38:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGI9O-00038u-99 for ram@iab.org; Wed, 01 Aug 2007 13:38:22 -0400
Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGI9M-0004lG-TE for ram@iab.org; Wed, 01 Aug 2007 13:38:22 -0400
Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 396621A386 for <ram@iab.org>; Wed, 1 Aug 2007 19:38:20 +0200 (CEST)
Received: from asus.free.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 0A9F91A334 for <ram@iab.org>; Wed, 1 Aug 2007 19:38:19 +0200 (CEST)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 01 Aug 2007 19:38:26 +0200
To: ram@iab.org
From: JFC Morfin <jefsey@jefsey.com>
Subject: Re: [RAM] First cut at routing & addressing problem statement
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-Id: <20070801173819.0A9F91A334@smtp7-g19.free.fr>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
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

On 05:54 01/08/2007, Robin Whittle said:
>Hi JFC Morphin,
>The missing point 3 is just a typo.

Thank you.

>  The other points you mention
>seem to involve long-term new architectural goals involving host
>changes.

Not that much. It is more a paradigm change that, I think, today 
TCP/IP can support - but not necessarily all its possible evolutions.

>I have approached the RADIR Problem Statement assuming it concerns
>a problem which requires a solution which is incrementally
>deployable and automatically enables existing hosts, without
>changes, to remain connected, but achieves important benefits such
>as multihoming, portability, TE etc. for many more end-users
>without adding to the growth in the global routing table.

IMHO there are several ways to achieve that. However, the real 
problem is that whatever the one being chosen it will have to 
co-exist with the current approach (designed along the old paradigm). 
In so doing it will live demonstrate that the Internet can support 
architectural multiplicity.

This means that the ROAP leads to the necessity of an IETF change of 
paradigm. And that its solution will be expressed under this new 
paradigm. Trying to express and solve it under the paradigm wich 
created it may turn being very complex, may be impossible?

jfc



_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram