Re: [nemo] Re: [Mip6] Consensus call on makingIDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document

Brijesh Kumar <kumarb@research.panasonic.com> Fri, 01 April 2005 13:15 UTC

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 IAA22701 for <mip6-web-archive@ietf.org>; Fri, 1 Apr 2005 08:15:07 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM6k-0001SE-VT for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 08:22:45 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLv0-0000Sw-VJ; Fri, 01 Apr 2005 08:10:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGp0q-0003C2-O7; Wed, 30 Mar 2005 21:02:24 -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 VAA23282; Wed, 30 Mar 2005 21:02:23 -0500 (EST)
Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGp7q-0005UR-7J; Wed, 30 Mar 2005 21:09:40 -0500
Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j2V218Lw006827; Wed, 30 Mar 2005 21:01:08 -0500
Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id D1EA63C815F; Wed, 30 Mar 2005 20:58:31 -0500 (EST)
Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62])by redwood.research.panasonic.com (Postfix) with ESMTP id C69F23C8157; Wed, 30 Mar 2005 20:58:31 -0500 (EST)
Received: from [69.248.17.64] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Wed, 30 Mar 2005 21:01:07 -0500
From: Brijesh Kumar <kumarb@research.panasonic.com>
To: Sri Gundavelli <sgundave@cisco.com>
Message-ID: <5e80e5a22c.5a22c5e80e@pintlmail.MITL.Research.Panasonic.COM>
Date: Wed, 30 Mar 2005 21:01:07 -0500
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003)
MIME-Version: 1.0
Content-Language: en
Subject: Re: [nemo] Re: [Mip6] Consensus call on makingIDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
X-imss-version: 2.8
X-imss-result: Passed
X-imss-scores: Clean:99.90000 C:18 M:1 S:5 R:5
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 01 Apr 2005 08:10:32 -0500
Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit

Hi Raj:

I too would support Sri's excellent analysis.

I am very surprised to see this consensus mail, given that during the last IETF meeting, several people had raised the concerns similar to what Sri has described  in his mail regarding that draft. Not  clear what has changed since then. 

--bk

----- Original Message -----
From: Sri Gundavelli <sgundave@cisco.com>
Date: Wednesday, March 30, 2005 5:38 pm
Subject: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a	MIP6/NEMO WGs document

> Hi Raj,
>       In the last IETF nemo meeting, we raised some
> issues on the approach chosen by this draft. We are
> not convinced that the draft has explored and narrowed
> down on the most common v4 traversal scenarios. The
> basic assumption of the draft that the v6 Home Agent's
> functionality is collapsed in to the transition gateway
> is not valid and just addresses one scenario. The
> requirement the draft imposes on having a V4 network
> terminating on the v6 home agent is probably not
> acceptible. Also, the draft's claim that they are
> avoiding one extra encap layer is not true, the moment
> you move the transition gateway from the home agent,
> indeed an extra encap layer is needed.
> 
> There were some other proposals for solving this problem
> and one being "draft-thubert-nemo-ipv4-traversal-01.txt",
> we should look at this work as well. Before we agree on
> a solution, we should atleast semantically agree on the
> problem statement and the scope. I remember you words,
> we should not boil the ocean in the process, Agreed !
> But, atleast we should have some amount of discussions on
> the problem scope. My 2c.
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> On Wed, 30 Mar 2005 Basavaraj.Patil@nokia.com wrote:
> 
> >
> > One of the major barriers to the deployment of Mobile IPv6 today is
> > the fact that most access networks are IPv4 only. A number of hosts
> > are already dual-stack capable. While Mobile IPv6 works well in IPv6
> > networks, it is essential that IPv6 mobility service continue to 
> work> even when the mobile host is attached to an IPv4 network. 
> The same
> > applies to a NEMO mobile router as well.
> >
> > A number of transition scenarios have been identified in IDs:
> > 1. draft-larsson-v6ops-mip-scenarios-01
> > 2. draft-tsirtsis-dsmip-problem-03
> > While discussion of these scenarios in the larger scope makes sense,
> > there is a need to focus on the most critical scenario that would
> > address the MIP6 host and router problem. The problem in a single
> > sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) 
> need> to be able to reach its (IPv6) home agent and services when 
> roaming in
> > and attached to an IPv4 access network."
> > It makes sense to focus on just this one scenario and solve the
> > problem immediately.
> >
> > The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a 
> MIPv6> mobile node or a NEMO mobile router roaming onto a IPv4 
> only access
> > network in a simple manner.
> > It is intended that the standardization of this solution in the 
> IETFs> MIP6 and/or NEMO working groups proceed. The working group 
> chairs have
> > reviewed and discussed this work item. It has also been 
> presented at
> > the MIP6 and NEMO WGs at IETF62.
> >
> > The chairs would like to hear your thoughts in order to see if there
> > is consensus to make it a WG document and progress it as a standards
> > track RFC. Comments should be sent to both the NEMO and MIP6 WGs.
> >
> > If we have consensus, then the document will be pursued as a 
> dual WG
> > item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt
> >
> > Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID:
> > 	For         	[  ]
> > 	Against 	[  ]
> >
> >
> > - MIP6 and NEMO WG chairs
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> 
> 


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6