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

From: Frank Xia <[email-masked]>
Date: Thu, 01 Apr 2010 09:48:09 -0500

Hi Mohana

Please check my replies again..

BR
Frank

-----Original Message-----
From: Mohana Jeyatharan [mailto:[email-masked]] 
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:[email-masked]] 
> 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. 

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

> 
> BR
> Frank
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 
>

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Mon, 5 Apr 2010 08:17:07 +0800

Hi Frank,

Please see below.

BR,
Mohana 

> Sent: Thursday, April 01, 2010 10:48 PM
> 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. 
> " 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.

> 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. 
 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Mohana Jeyatharan
> > draft-jeyatharan-mext-flow-tftemp-reference-00 and get the direct 
> > feedback from the WG.
> > 
> 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
> >

---

From: Frank Xia <[email-masked]>
Date: Mon, 05 Apr 2010 12:04:32 -0500

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:[email-masked]] 
Sent: Sunday, April 04, 2010 7:17 PM
To: Frank Xia; mext
Subject: RE: [MEXT] Any Comments

Hi Frank,

Please see below.

BR,
Mohana

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 6 Apr 2010 08:26:05 +0800

Hi Frank,

Please see below.

BR,
Mohana 

> Sent: Tuesday, April 06, 2010 1:05 AM
> I don't think draft-ietf-mext-flow-binding-06.txt need any 
> changes.

Yes, correct.  We are not proposing any changes to
draft-ietf-mext-flow-binding-06.txt.
In the above draft, the format of the traffic selector can be anything.
I mean the TS field can have any value.
One is the binary format with a specific value for TS field.  What we
are proposing is the TFT reference as another format for the traffic
selector sub option. That is all.

 However, I think it is very useful to document the 
> integration of them. 

Yes, some of the integration with the flow binding mechanism is captured
in the flow-tftemp-reference draft.  However, there is no change to the
flow binding mechanism.  Just use the TFT ref traffic selector suboption
when creating flowbinding rules.
> > 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.
> 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.
> 
> > 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.
> > 
> > 
> 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.
> 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
> > >