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

Sri Gundavelli <sgundave@cisco.com> Wed, 30 March 2005 23:30 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 SAA10280 for <mip6-web-archive@ietf.org>; Wed, 30 Mar 2005 18:30:33 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmkw-0002Y0-9X for mip6-web-archive@ietf.org; Wed, 30 Mar 2005 18:37:50 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmb6-0003pA-00; Wed, 30 Mar 2005 18:27:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmb4-0003oU-Ek; Wed, 30 Mar 2005 18:27: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 SAA09848; Wed, 30 Mar 2005 18:27:36 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmi4-0002Sp-Ql; Wed, 30 Mar 2005 18:34:53 -0500
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2005 18:47:37 -0500
X-IronPort-AV: i="3.91,136,1110171600"; d="scan'208"; a="42560579:sNHT30631260"
Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2UNRQjJ016730; Wed, 30 Mar 2005 18:27:27 -0500 (EST)
Date: Wed, 30 Mar 2005 15:27:26 -0800
From: Sri Gundavelli <sgundave@cisco.com>
To: Vijay Devarapalli <vijayd@iprg.nokia.com>
Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document
In-Reply-To: <424B32A4.9040408@iprg.nokia.com>
Message-ID: <Pine.GSO.4.58.0503301520590.29341@irp-view8.cisco.com>
References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <Pine.GSO.4.58.0503301420440.29341@irp-view8.cisco.com> <424B32A4.9040408@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
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: b2809b6f39decc6de467dcf252f42af1


Hi Vijay,

On Wed, 30 Mar 2005, Vijay Devarapalli wrote:

> Sri,
>
> Sri Gundavelli wrote:
> > 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.
>
> if I understood you right, your concern is about how to make
> an IPv6 HA with an IPv4 interface accesible through the IPv4
> Internet. right?

The question is not about configuring a v4 address on the
interface of v6 home agent, it about the termination point
of the v4 network and the placement of a v6 home agent. You
cannot expect the v6 home agent and the transition gateway
service to be co-located. The point is that we should identify
the practical deployment sceanarios and go from there.

>
> > 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.
>
> we do want to keep it to just one level of encapsulation.
>

Other way to say is we would not an extra encap layer, when
the home agent and the transition gateway functions are spread
out.



> Vijay
>
> >
> > 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
>

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