RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document

Sri Gundavelli <sgundave@cisco.com> Fri, 01 April 2005 18:07 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22683 for <nemo-archive@lists.ietf.org>; Fri, 1 Apr 2005 13:07:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQVc-00075q-RQ; Fri, 01 Apr 2005 13:04:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQVa-00075a-7p; Fri, 01 Apr 2005 13:04:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22475; Fri, 1 Apr 2005 13:04:35 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQcw-00053V-Bn; Fri, 01 Apr 2005 13:12:15 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2005 10:03:59 -0800
X-IronPort-AV: i="3.91,141,1110182400"; d="scan'208"; a="625088265:sNHT5651333394"
Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j31I3ugF013136; Fri, 1 Apr 2005 10:03:57 -0800 (PST)
Date: Fri, 01 Apr 2005 10:03:56 -0800
From: Sri Gundavelli <sgundave@cisco.com>
To: Pekka Savola <pekkas@netcore.fi>
Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document
In-Reply-To: <Pine.LNX.4.61.0504012017320.20303@netcore.fi>
Message-ID: <Pine.GSO.4.58.0504010958540.17502@irp-view7.cisco.com>
References: <7892795E1A87F04CADFCCF41FADD00FCAD82EF@xmb-ams-337.emea.cisco.com> <Pine.LNX.4.61.0504012017320.20303@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: nemo@ietf.org, mip6@ietf.org, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Vijay Devarapalli <vijayd@iprg.nokia.com>, Henrik Levkowetz <henrik@levkowetz.com>, Basavaraj.Patil@nokia.com
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org


On Fri, 1 Apr 2005, Pekka Savola wrote:

> On Fri, 1 Apr 2005, Pascal Thubert (pthubert) wrote:
> > Even better would be that this "box in the DMZ" terminates V4, and sends
> > packets to the HA in IPv6. Say, doing some NAT-PT instead of tunneling,
> > classical alternates.
>
> Please, don't even consider translation.
>
> You may be interested of the following:
>
> "Reasons to Move NAT-PT to Experimental"
> draft-ietf-v6ops-natpt-to-exprmntl-00
>
> AFAIK, that has just recently been forwarded to the IESG for
> processing.
>
> > Seems to me that the line if thought that starts at your "box in the
> > DMZ" ends up being With Doors.
> >
> > With Doors, the "box in the DMZ" is the Doors gateway between IPv4 and
> > IPv6.
>
> Doors does not solve the problem if the strict requirement is avoiding
> "extra" encapsulation, right?  (I may not buy that requirement myself,
> but we should at least get to consensus whether it's one or not.)
>

Hi Pekka,

I agree with you that saving the extra encap should not be
the central focus. If saving few bytes is of paramount
interest, there are header compression techniques that we
can apply to doors. Choosing a solution by basing this as
the central argument is not right.

Sri