Re: [RAM] Different approaches for different protocols

Dino Farinacci <dino@cisco.com> Thu, 20 December 2007 01:35 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 1J5AKA-0003mX-6T; Wed, 19 Dec 2007 20:35:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5AK9-0003mS-8S for ram@iab.org; Wed, 19 Dec 2007 20:35:45 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5AK7-0004tL-2J for ram@iab.org; Wed, 19 Dec 2007 20:35:45 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Dec 2007 17:35:32 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBK1ZWkg012433; Wed, 19 Dec 2007 17:35:32 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBK1ZFl7019875; Thu, 20 Dec 2007 01:35:28 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 17:35:18 -0800
Received: from dhcp-171-71-55-230.cisco.com ([171.71.55.230]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 17:35:17 -0800
Message-Id: <D0568E34-C755-4068-987B-819A37F4FE95@cisco.com>
From: Dino Farinacci <dino@cisco.com>
To: RJ Atkinson <rja@extremenetworks.com>
In-Reply-To: <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.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:35:16 -0800
References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com> <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 20 Dec 2007 01:35:17.0887 (UTC) FILETIME=[93A210F0:01C842A8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1864; t=1198114532; x=1198978532; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[RAM]=20Different=20approaches=20for=20 different=20protocols |Sender:=20; bh=9UEhUa5bN5szz0YiXJHu6hkIdahgXNj9MCT5wB6csNQ=; b=H09InAg3Tv8LyclA+mZQFaaY6W2ttRzWjy46jiIlhuTm/zls6Qlkryn79P iE3yFSoTnknPxqBgK/S82gx/3eS+7PpeNFi2Sbnsiba/BnFDP88LhMX2jAmY wToF2g7WLbzNEuFncA1pK5lViMa6nyhypRP3fce4uYe+BD8MS8eqQ=;
Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: ram@iab.org
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

All good points, thanks.

Dino

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