Subject: [netext] Review of I-D: draft-hui-netext-service-flow-identifier

From: <[email-masked]>
Date: Wed, 15 Jul 2009 18:31:15 +0200

After reviewing the I-D draft-hui-netext-service-flow-identifier-00, I
had a few questions for the authors:

1. In figure 1:
   - What does it mean to start a new service flow?
   
As per PMIP6 when the MN attaches to a MAG as part of initial
attachment the BCE at the LMA is created and the bi-directional tunnel
between the MAG/LMA established. In the figure you show a PBU with
SFID option being sent after the MN starts a new SF.

Can you elaborate on this statement:
"2. When a new service flow of the mobile node is started, the data
      packet of this service will be routed to the mobile access gateway,
      which will trigger the service flow proxy binding update"

2. I am also not clear about what sort of control is expected to be
enabled by including an SFID in the PBU. The following sentence in the
introduction: 
"Hence, the mobile access gateway can bind mobile node's each service
flow to its home network prefix, respectively. Therefore, the mobile
node's multiple service flows can be separately controlled based on
the service flow identifier."

I am not sure what the above means.

3. Assuming you do have granularity greater than a single tunnel
between the MAG/LMA for the MNs traffic, do you really need an SFID?
Is'nt the v6 address itself or in the case of GRE keys being used, the
GRE key sufficient in terms of an identifier?

4. In sec 4 : 
"Assume a mobile node establishes two service flows, called SF1 and
   SF2."

Does the MN have a single HNP?
Is the MN attached to the MAG via different interfaces?
If not, what causes the MAG to establish separate tunnels with the LMA
for each service flow?
Assuming that there is a BCE for the MN already, do you modify the
existing BCE or extend it?

Obviously you are making certain assumptions about service flows and
rules at the MAG that would trigger the establishment of a unique
tunnel to handle some traffic to/from the MN. These assumptions are
missing. Can you provide references to such assumptions? Or state the
assumptions in this document itself.

Lastly, the discussion of flow-binding is part of the NetExt2 BoF at
IETF75. Hence we will not consider this I-D as part of the NetExt WG
meeting at IETF75. 

-Raj

---

From: Min Hui <[email-masked]>
Date: Fri, 17 Jul 2009 20:03:27 +0800

Hi Raj,

Thanks for the reply, pls see my answer in line.

- Hui Min

>      which will trigger the service flow proxy binding update"

Start a new service flow means the MN send IP packet with parameters
different with previous ones. The parameter used to defined a service
flow is described in the "Service Flow Description Option". In this
draft the PMIP6 is modified to sent PBU whenever a new service flow
startes,  so that the tunnel can be set for each service flow but not
the interface. MAG is responsible for checking the IP packet and
decide whether to send the PBU or not.

> I am not sure what the above means.

QoS, content charging, traffic control can be enabled by tunnelling
service flow respectively according to SFID.

> GRE key sufficient in terms of an identifier?

GRE key is indeed the identifier of PMIP tunnel, but the PMIP tunnel
will not be per service flow basis if the SFID is lacked. That's why
we need SFID.

> Does the MN have a single HNP?

Both single HNP and multiple HNP are supported.

> Is the MN attached to the MAG via different interfaces?

Both single interface and multiple interfaces are supported.

> If not, what causes the MAG to establish separate tunnels with the LMA

QoS, content charging, etc.
If all the service flows use single tunnel, different services cannot
be treated separately.

> existing BCE or extend it?

I think it will modify BCE.

> assumptions in this document itself.

The assumption is that the tunnel is established for each interface of
MN, and I believe the description of BCE in section 5.1 of RFC5213
shows this assumption is correct. I will state the detailed reference
in the updated draft, thanks for your comment.

> IETF75. Hence we will not consider this I-D as part of the NetExt WG

Ok, I see. Thanks.

>
> -Raj
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>