Re: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00

Sri Gundavelli <sgundave@cisco.com> Sun, 25 January 2009 18:47 UTC

Return-Path: <mip4-bounces@ietf.org>
X-Original-To: mip4-archive@optimus.ietf.org
Delivered-To: ietfarch-mip4-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFEE3A682D; Sun, 25 Jan 2009 10:47:39 -0800 (PST)
X-Original-To: mip4@core3.amsl.com
Delivered-To: mip4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE763A6774 for <mip4@core3.amsl.com>; Sun, 25 Jan 2009 10:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGWqaIN0EOr4 for <mip4@core3.amsl.com>; Sun, 25 Jan 2009 10:47:38 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F294D3A682D for <mip4@ietf.org>; Sun, 25 Jan 2009 10:47:37 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,322,1231113600"; d="scan'208";a="60924042"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2009 18:47:20 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0PIlKm2008750; Sun, 25 Jan 2009 10:47:20 -0800
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0PIlKLE028996; Sun, 25 Jan 2009 18:47:20 GMT
Date: Sun, 25 Jan 2009 10:47:20 -0800
From: Sri Gundavelli <sgundave@cisco.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
In-Reply-To: <868721.88015.qm@web111408.mail.gq1.yahoo.com>
Message-ID: <Pine.GSO.4.63.0901251036090.17280@irp-view13.cisco.com>
References: <1d38a3350901220252y17d6f14cs23b107afd22d6eb2@mail.gmail.com> <868721.88015.qm@web111408.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1903590565-1232909240=:17280"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5916; t=1232909240; x=1233773240; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20<sgundave@cisco.com> |Subject:=20Re=3A=20[Mip4]=20Questions=20on=20draft-gundave lli-mip4-multiple-tunnel-support-00 |Sender:=20; bh=e84SYCxFDAjPJsulDmT/Q/BoRDJ2hnYsV4n5bmvLJAs=; b=piLr5XOFItTJqzHIuB7ecLZPTTIeX9+SFeZ/3iy0fvVoGEY++XHxqEcWju msbQerB7uHv+usYylqp0GkN6uWURmT44fAu8FmYV2sKjqLZAmuQsB5SYspoV HXtJf7Bvsr;
Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: Hui Deng <denghui02@gmail.com>, mip4@ietf.org
Subject: Re: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org

Hi Hui,

Thanks for the review. Please see inline.


> ________________________________
> From: Hui Deng <denghui02@gmail.com>
> To: Sri Gundavelli <sgundave@cisco.com>
> Cc: mip4@ietf.org
> Sent: Thursday, January 22, 2009 4:52:41 AM
> Subject: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00
>
>
> Hi, Sri,
>
> I have several questions regarding to your draft.
>
> 1) will you use the same AE between HA and MN on different interfaces?


Auth extension ? Sure, the Security association however keyed
using HoA or NAI, will remain the same. The AE will be generated
for each of the RRQ sent.

> 2) how do you generate a label for each interface?

We currently allow the IfType and the Binding Id. We should probably
allow the label to be specified as well, our implementation uses
the explicit labels. Typically, the label is configured as part
of configuring the roaming interface on the mobile router. Each
of the selected roaming interfaces can be given a explicit label.

> 3) Where does the access Technology Type Registry is defined?

ATT registry


> 4) why don't allow mobile node use multiple interface when one of it stay at home?
>

This can be fixed. Initial thoughts were that this may not be so useful,
but will fix it in the next rev, for simultaneous home and roam support.


Regards
Sri

> thanks
>
> -Hui
>
>
> 2009/1/20 Sri Gundavelli <sgundave@cisco.com>
>
> Hi George,
>
> Sorry for the late reply. Please see inline.
>
>
>
> On Wed, 14 Jan 2009, George Tsirtsis wrote:
>
>
> Hi Sri,
>
> I just had a look at the draft.
> Since I was not in the last IETF meeting could you summarize what the
> plan is with this draft? Is this something the WG considers taking up?
>
>
> I hope so. That's the plan and there is interest. We need this for
> our mobile router deployments.
>
>
>
>
> If yes, I think it would be useful to spell out what the scope of this
> work is in comparison to the equivalent work in the MEXT (i.e., MCoA
> and Flow Movement). I did this early on for DSMIPv4 and it helped
> things significantly.
>
>
> Ok. The problem statement between MCOA4 and MCOA6 is similar. The
> ability for the mobile to setup multiple tunnels to the home agent
> through different interfaces, is largely same. The presence of foreign
> agent/types of registrations, NAT presence introduces some differences
> and issues.
>
>
>
>
> BTW, I am not sure I like the whole notion of 'Interface bandwidth".
> This is something notoriously difficult to set right and make sense
> of, especially on wireless links. Instead the rough link priority
> adopted in MIPv6-MCoA is easier to deal with and should satisfy your
> needs, without turning this into a QoS protocol...which would be a
> nightmare..
>
>
>
> The draft is exposing the information about the interface through which
> a mobile node is attached and marks the binding associated with this
> attach. The interface type (WiMAX, WiFI, LTE ..etc) will definetly provide
> a sufficient hint for the home agent. In some radio environments, if
> the link bandwidth is predictable, it can certainly expose the same to
> the home agent. I agree with you that its not always predictable, hence
> it is optional, making it useful only when present. The exposed parameters
> are sufficient for the tunnel peers to build efficient traffic policies
> and leverage the links in a much more efficient manner.
>
> Sri
>
>
>
>
>
>
>
>
> Regards
> George
>
> On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli <sgundave@cisco.com> wrote:
>
>
> Please comment on this work item. We presented this
> at Minneapolis.
>
>
> Sri
>
>
> ---------- Forwarded message ----------
> Date: Mon,  8 Dec 2008 00:51:42 -0800 (PST)
> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> To: sgundave@cisco.com
> Cc: kleung@cisco.com
> Subject: New Version Notification for
>   draft-gundavelli-mip4-multiple-tunnel-support-00
>
>
> A new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-00.txt
> has been successfuly submitted by Sri Gundavelli and posted to the IETF
> repository.
>
> Filename:        draft-gundavelli-mip4-multiple-tunnel-support
> Revision:        00
> Title:           Multiple Tunnel Support for Mobile IPv4
> Creation_date:   2008-12-08
> WG ID:           Independent Submission
> Number_of_pages: 17
>
> Abstract:
> This document defines extensions to Mobile IPv4 protocol for allowing
> a mobile node or a mobile router with multiple interfaces to register
> a care-of address for each of the available interfaces and to
> simultaneously establish multiple Mobile IP tunnels to the home
> agent, each through a different interface path.  This capability is
> required for enabling a mobile node to utilize all the available
> wireless access links and build an higher aggregated data pipe to the
> home agent by setting the home address reachability over all of those
> tunnel paths.
>
>
>
> The IETF Secretariat.
>
>
> --
> Mip4 mailing list: Mip4@ietf.org
>  Web interface: https://www.ietf.org/mailman/listinfo/mip4
>   Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>
>
> --
> Mip4 mailing list: Mip4@ietf.org
>   Web interface: https://www.ietf.org/mailman/listinfo/mip4
>    Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>
>
>
--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/