Re: [MEXT] GRE support in DSMIPv6 - AD review

Sri Gundavelli <sgundave@cisco.com> Mon, 19 January 2009 18:09 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC583A69CE; Mon, 19 Jan 2009 10:09:43 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4176D3A67D7 for <mext@core3.amsl.com>; Mon, 19 Jan 2009 10:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.535
X-Spam-Level:
X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 FUwy029WwbCG for <mext@core3.amsl.com>; Mon, 19 Jan 2009 10:09:41 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 757553A69CE for <mext@ietf.org>; Mon, 19 Jan 2009 10:09:41 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="130785693"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2009 18:09:25 +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 n0JI9Pmj029185; Mon, 19 Jan 2009 10:09:25 -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 n0JI9Pbh002031; Mon, 19 Jan 2009 18:09:25 GMT
Date: Mon, 19 Jan 2009 10:09:25 -0800
From: Sri Gundavelli <sgundave@cisco.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
In-Reply-To: <703169.3551.qm@web111408.mail.gq1.yahoo.com>
Message-ID: <Pine.GSO.4.63.0901190952430.17388@irp-view13.cisco.com>
References: <C596274D.B18A%hesham@elevatemobile.com> <703169.3551.qm@web111408.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-342241519-1232388565=:17388"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2184; t=1232388565; x=1233252565; 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[MEXT]=20GRE=20support=20in=20DSMIPv6=2 0-=20AD=20review |Sender:=20; bh=nx/biQ2rkJkOhyo/yRB7U77ACxZPmo+jfX+MtIScysg=; b=bjDI4MPZ/R2kvmyfBLSm6gck1FEVpvSA+QCrcFgRp9q0N4gzMD6Opb97IX jqc0be9oSyAepBjFy0BuGnalcfgycbsOs41nC8EDjUGPfAAvAzTDpTezTmRn STzNPDUU6O;
Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: Jari Arkko <jari.arkko@piuha.net>, mext@ietf.org, Pasi.Eronen@nokia.com
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org


On Fri, 16 Jan 2009, Behcet Sarikaya wrote:

> [behcet] I couldn't understand why MN would need to support GRE. Can someone explain the use case?
>  

This issue was discussed at length. Many reasons were cited as why the
GRE encapsulation mode may be needed in client-based mobility and why
it should not be restricted to network elements alone.

The LMA element in Proxy Mobile IPv6 is a feature extension to the
Mobile IPv6 home agent. They have a strong relation. If some one
implements home agent function, implements the data plane with all
the hardware support for GRE and it cant be leveraged when supporting
client-based mobile nodes ? Its the same home agent that serves both
types of nodes.

The options that we are standardizing NETLMM or MEXT, each should not
take a different path. Its not that we have one revocation option for
PMIP, one for NEMO and the other for MIP6. Keeping them together will
save implementors to leverage all these features and resources across.

GRE is another enapsulation mode, it exists with much richer semantics
than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying
I support this for carrying IPX/AT traffic, but the point that its a
useful encapsation mode that exists in MIP4 and cant be ignored for
good reasons.

Sri










> Thanks,
>  
> Behcet
>
>
>> Hi Pasi, Hesham,
>>
>> The TLV header was specified in the DS-MIPv6 document after rather a
>> long and acrimonious debate on the former MIP6 mailing list. There were
>> atleast two consensus calls that were run at that time.
>
> => I don't realy want to get into that, we all know there was no concensus
> and we had to teleconference to come up with the existing method
>
> Anytime you have
>> a UDP header with IPv4/IPv6/GRE header following it, you need the TLV
>> header.
>
>
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext