Re: [netext] Comment on draft-gundavelli-netext-pmipv6-sipto-option-01

Hidetoshi Yokota <yokota@kddilabs.jp> Tue, 26 July 2011 01:20 UTC

Return-Path: <yokota@kddilabs.jp>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA4921F86DC for <netext@ietfa.amsl.com>; Mon, 25 Jul 2011 18:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMhRudJeyA9V for <netext@ietfa.amsl.com>; Mon, 25 Jul 2011 18:20:28 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id F127B21F86CA for <netext@ietf.org>; Mon, 25 Jul 2011 18:20:24 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 43F34174812A; Tue, 26 Jul 2011 10:20:23 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddilabs.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro2gHUHq0QzE; Tue, 26 Jul 2011 10:20:23 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0DBE017480DE; Tue, 26 Jul 2011 10:20:23 +0900 (JST)
Received: from [127.0.0.1] (yokotaiMac.mn.mip.kddilabs.jp [172.19.90.27]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 715571B9B1; Tue, 26 Jul 2011 10:18:59 +0900 (JST)
Message-ID: <4E2E1655.4070908@kddilabs.jp>
Date: Tue, 26 Jul 2011 10:20:21 +0900
From: Hidetoshi Yokota <yokota@kddilabs.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Sri Gundavelli <sgundave@cisco.com>
References: <CA50D80B.22490%sgundave@cisco.com>
In-Reply-To: <CA50D80B.22490%sgundave@cisco.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Comment on draft-gundavelli-netext-pmipv6-sipto-option-01
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 01:20:28 -0000

Hi Sri,

Thanks for your clarification. SIPTO capability extension for PMIP is as
much important. I just thought if these two capabilities (flow mobility
and offload) could be combined as a protocol. Either to use the option
in your draft or to define a new flag in PMIP flow mobility draft. I
would like to see the discussion in the meeting.

Regards,
-- 
Hidetoshi

(2011/07/24 11:56), Sri Gundavelli wrote:
> Hi Yokota-san,
> 
> Sure. The options have similar properties, they both use the 6088 formats
> for flow selectors. While 6089 identifies the flows for a given access, and
> does not cover offload. We could have surely extended this option to DSMIP,
> but that is not our main interest at this point of time. Good to see your
> interest on SIPTO, we believe this is burning issue for every operator as
> well.
> 
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> On 7/23/11 5:47 PM, "Hidetoshi Yokota"<yokota@kddilabs.jp>  wrote:
> 
>> Hi Sri,
>>
>> (2011/07/22 1:09), Sri Gundavelli wrote:
>>> Hi Yokota-san,
>>>
>>> Thanks for your review.
>>>
>>> This is essentially about IPv4 traffic offload, not about flow distribution
>>> for multi-access terminals/flow mobility. This is not about tunnel/interface
>>> selection for a given flow, but rather about the IPv4 flows for NAT offload
>>> at the access edge/MAG.
>>
>> I understand the mechanism that this spec describes. I just thought that
>> the IP Traffic Offload Selector Option in your draft and the FID
>> mobility option in RFC6089 have the equivalent capability from the
>> perspective of carrying the (IPv4) traffic selector. Anyway, I hope that
>> this will activate the SIPTO discussion in IETF as well.
>>
>> Regards,
> 
> 
> 
>