Re: [RAM] Different approaches for different protocols

RJ Atkinson <rja@extremenetworks.com> Wed, 19 December 2007 22:09 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 1J576H-0000ZJ-Sc; Wed, 19 Dec 2007 17:09:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J576G-0000ZE-Dv for ram@iab.org; Wed, 19 Dec 2007 17:09:12 -0500
Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J576E-0001E1-Hm for ram@iab.org; Wed, 19 Dec 2007 17:09:12 -0500
Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071219220910.LGVI24467.eastrmmtao103.cox.net@eastrmimpo02.cox.net> for <ram@iab.org>; Wed, 19 Dec 2007 17:09:10 -0500
Received: from [10.30.20.71] ([68.10.115.26]) by eastrmimpo02.cox.net with bizsmtp id Sm8k1Y0050aEP1Q0000000; Wed, 19 Dec 2007 17:08:44 -0500
Message-Id: <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com>
From: RJ Atkinson <rja@extremenetworks.com>
To: ram@iab.org
In-Reply-To: <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [RAM] Different approaches for different protocols
Date: Wed, 19 Dec 2007 17:09:09 -0500
References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com>
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
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  19 Dec 2007, at 15:32, Dino Farinacci wrote:
>> 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).
>
> So let me propose something:
>
> 1) For IPv4, use LISP encapsulation as spec'ed in the -05 draft.
> 2) For IPv6, use header address translation (of the high-order 8- 
> bytes),
>   spec that out as GSE++.
> 3) Have both use the same mapping database infrastructure.
>
> Comments?
>
> If we added 2) to the LISP draft would people be happy with that?



Hmm.

Suggestions:

(A) I'd encourage keeping your concepts (1) and (2) separate,
in separate drafts and ideally with separate names, at least for now.

(B) Separately, modularity and clean architecture would argue for
keeping the mapping database structure separately specified
from any other bits of protocol design.

Rationale:

For my first suggestion (A), I'll note that approach (1) above
might be used for both IPv4 and IPv6 (at least in theory),
while approach (2) above isn't obviously applicable to IPv4.

For my second suggestion (B), one might use the currently proposed
LISP encapsulation, but with some alternative (not yet designed
or proposed) mapping database schema [or vice versa].  So keeping
things separate and modular seems beneficial all around for now.

My two cents.

Ran


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