Re: [MEXT] Any Comments fordraft-jeyatharan-mext-flow-tftemp-reference-00

Frank Xia <xiayangsong@huawei.com> Mon, 05 April 2010 17:04 UTC

Return-Path: <xiayangsong@huawei.com>
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 93B133A67EA for <mext@core3.amsl.com>; Mon, 5 Apr 2010 10:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.705
X-Spam-Level: **
X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1]
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 5j-b4+N5BrFG for <mext@core3.amsl.com>; Mon, 5 Apr 2010 10:04:48 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4545F3A679C for <mext@ietf.org>; Mon, 5 Apr 2010 10:04:48 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0E00GT3Y3OKO@szxga01-in.huawei.com> for mext@ietf.org; Tue, 06 Apr 2010 01:04:36 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0E0062MY3NZ1@szxga01-in.huawei.com> for mext@ietf.org; Tue, 06 Apr 2010 01:04:35 +0800 (CST)
Received: from X24512z ([10.124.12.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0E00C07Y3K8N@szxml04-in.huawei.com> for mext@ietf.org; Tue, 06 Apr 2010 01:04:35 +0800 (CST)
Date: Mon, 05 Apr 2010 12:04:32 -0500
From: Frank Xia <xiayangsong@huawei.com>
In-reply-to: <5F09D220B62F79418461A978CA0921BD04051A7B@pslexc01.psl.local>
To: 'Mohana Jeyatharan' <Mohana.Jeyatharan@sg.panasonic.com>, 'mext' <mext@ietf.org>
Message-id: <000c01cad4e2$11975bf0$510c7c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AcrPo04uq9v8I2dXQ2Sgwl93JNmhEgBe7vggAAPUADAAHnVEgACq9HogACMagSA=
References: <00a001cad1aa$59b6d400$510c7c0a@china.huawei.com> <5F09D220B62F79418461A978CA0921BD04051A7B@pslexc01.psl.local>
Subject: Re: [MEXT] Any Comments fordraft-jeyatharan-mext-flow-tftemp-reference-00
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/mail-archive/web/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>
X-List-Received-Date: Mon, 05 Apr 2010 17:04:49 -0000

Hi Mohana

Hi Mohana

I don't think draft-ietf-mext-flow-binding-06.txt need
any changes. However, I think it is very useful to 
document the integration of them. 

BR
Frank

-----Original Message-----
From: Mohana Jeyatharan [mailto:Mohana.Jeyatharan@sg.panasonic.com] 
Sent: Sunday, April 04, 2010 7:17 PM
To: Frank Xia; mext
Subject: RE: [MEXT] Any Comments
fordraft-jeyatharan-mext-flow-tftemp-reference-00

Hi Frank,

Please see below.

BR,
Mohana 

> -----Original Message-----
> From: Frank Xia [mailto:xiayangsong@huawei.com] 
> Sent: Thursday, April 01, 2010 10:48 PM
> To: Mohana Jeyatharan; 'mext'
> Subject: RE: [MEXT] Any Comments 
> fordraft-jeyatharan-mext-flow-tftemp-reference-00
> 
> Hi Mohana
> 
> Please check my replies again..
> 
> BR
> Frank
> 
> -----Original Message-----
> From: Mohana Jeyatharan [mailto:Mohana.Jeyatharan@sg.panasonic.com]
> Sent: Wednesday, March 31, 2010 7:27 PM
> To: Frank Xia; mext
> Subject: RE: [MEXT] Any Comments
> fordraft-jeyatharan-mext-flow-tftemp-reference-00
> 
> Hi Frank,
> 
> Thank you for some quick comments.  
> 
> Please see some replies below.
> 
> BR,
> Mohana 
> 
> > -----Original Message-----
> > From: Frank Xia [mailto:xiayangsong@huawei.com]
> > Sent: Thursday, April 01, 2010 6:19 AM
> > To: Mohana Jeyatharan; 'mext'
> > Subject: RE: [MEXT] Any Comments
> > fordraft-jeyatharan-mext-flow-tftemp-reference-00
> > 
> > Hi Mohana
> > 
> > I had a quick glance.
> > It is interesting. 
> > 
> > Some clarification questions are below:
> > 1)is TFT(Traffic Flow Template)implementation
> >   mandatory for 3GPP mobile node?
> >   I think so from your document.
> 
> If 3GPP network entitiy decides per flow QoS treatment needed 
> for a given prefix/HoA, then dedicated bearers will be 
> created by network and such TFTs will be assigned.  In such a 
> case, the 3GPP MN needs to understand the TFT when sending 
> data.  Thus I would say it is mandatory for the MN. However, 
> it is not mandatory to create dedicated bearers. If there are 
> no dedicated bearers and TFT, the MN will not have TFTs stored in it. 
> Frank=>I am sure about your answer, yes or not. 
> " If 3GPP network entitiy decides per flow QoS treatment 
> needed for a given prefix/HoA ..".  I assume per flow 
> treatment is a prerequisite for 3GPP when we talk about flow 
> binding topic. So, I think your answer is yes. 

Yes, the answer is yes. TFT feature for MN is mandatory.

> > 2)is it has the same descriptive capability as
> >   draft-ietf-mext-binary-ts-04.txt?
> >   I think so.
> The TFT reference traffic selector suboption is different 
> from the binary TS traffic selector sub option. In TFT Ref 
> sub option, the data field only carries the bearer ID to 
> describe the packet filters.
> Multiple packet filters are collapsed to a single bearer ID. 
> Moreover, when there is change in packet filters tied to TFT, 
> a simple refresh flowbinding would do as described in the 
> TFT-ref draft.  Thus there are some subtle differences 
> between the two.
> 
> 
> However, in highlevel both are describing flows when setting 
> filter rules.
> But, what we are highlighting here is that, when TFTs are 
> present at the 3g bearer filtering table, and the MN wants 
> such flows to be sent via 3G path, a simple reference to the 
> TFT is an easier way to set flow binding rules. 
> Frank=>Did you contribute this to 3GPP?  IMHO, TFT is a 
> better way to incorporate into current 3GPP system.

The TFT reference as a new traffic selector sub-option format needs to
be specified in IETF.  Following that it can be used in 3GPP. Yes, using
a TFT to describe the flows in flow binding operation is useful in 3GPP
scenarios as highlighted in the draft. 
 
> > 
> > BR
> > Frank
> > 
> > -----Original Message-----
> > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] 
> On Behalf 
> > Of Mohana Jeyatharan
> > Sent: Monday, March 29, 2010 7:53 PM
> > To: mext
> > Subject: [MEXT] Any Comments for
> > draft-jeyatharan-mext-flow-tftemp-reference-00
> > 
> > Hi all,
> > 
> > During last IETF-77 MEXT session we could not present the ID 
> > draft-jeyatharan-mext-flow-tftemp-reference-00 and get the direct 
> > feedback from the WG.
> > 
> > Would really appreciate if we can get some comments on this 
> draft and 
> > general opinion about this draft from the WG.
> > 
> > The mechanism highlighted in this draft is a simple 
> mechanism to set 
> > flow binding rules for flows that have descriptors present 
> at the HA 
> > and MN, using a reference to the TFT as a flow descriptor.
> > 
> > Thanks.
> > 
> > BR,
> > Mohana
> > 
> > _______________________________________________
> > MEXT mailing list
> > MEXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/mext
> > 
> > 
> 
>