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

"Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com> Thu, 01 April 2010 00:28 UTC

Return-Path: <Mohana.Jeyatharan@sg.panasonic.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 AEC9B3A68E8 for <mext@core3.amsl.com>; Wed, 31 Mar 2010 17:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.572
X-Spam-Level: **
X-Spam-Status: No, score=2.572 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_37=0.6]
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 b4C-K1PujdVL for <mext@core3.amsl.com>; Wed, 31 Mar 2010 17:28:27 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id A4B793A65A6 for <mext@ietf.org>; Wed, 31 Mar 2010 17:28:27 -0700 (PDT)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id o310SvDu000037; Thu, 1 Apr 2010 09:28:57 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id o310Swm19753; Thu, 1 Apr 2010 09:28:58 +0900 (JST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 01 Apr 2010 08:27:23 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD03FFE909@pslexc01.psl.local>
In-Reply-To: <001c01cad120$374fdd60$510c7c0a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MEXT] Any Comments fordraft-jeyatharan-mext-flow-tftemp-reference-00
Thread-Index: AcrPo04uq9v8I2dXQ2Sgwl93JNmhEgBe7vggAAPUADA=
From: Mohana Jeyatharan <Mohana.Jeyatharan@sg.panasonic.com>
To: Frank Xia <xiayangsong@huawei.com>, mext <mext@ietf.org>
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: Thu, 01 Apr 2010 00:28:29 -0000

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. 

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