Subject: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option

From: <[email-masked]>
Date: Thu, 24 May 2012 22:19:06 +0000

My review comments for this I-D below:

General comment: The document quality needs improvement before it
would be considered ready for being forwarded to the IESG. There is a
lack of readability in this I-D. Authors assume that readers are
familiar with 3GPP architectures or offloading features. Recommend
explaining the problem and proposed solution much more clearly.

1. The abstract is intended to at least give a high level perspective
on what the I-D is about. Current abstract does not do that. Other
than the authors or someone following this work very closely, I doubt
if anyone can understand what this document is specifying.

2. What are "access technology domains"?

3. "For providing IP mobility support to a mobile node irrespective of the
   access network to which it is attached." ???? Rephrase.

4. "the 3GPP S2a Proxy Mobile IPv6 [TS23402] interface," Is this an
interface or a reference point?

5. "...is providing the needed protocol glue." Protocol glue for what?

6. " The mobile node's IP traffic is
   always tunneled back from the mobile access gateway [RFC5213] in the
   access network to the local mobility anchor in the home network."

   The MN could use the local address provided by the access-network
   for some applications, right? Just having the S2a interface does
   not imply that all traffic is routed back to the LMA, right?

7. "Not all IP traffic need to be
   routed back to the home network, some of the non-essential traffic
   which does not require IP mobility support can be offloaded at the
   mobile access gateway in the access network."

   What is non-essential traffic? Can you give some examples. And what
   happens if such traffic does not have IP mobility support?

8. "This approach provides
   greater leverage and efficient usage of the mobile packet core which
   help lowering transport cost."

   Greater leverage of what? Sounds like too much of marketing buzz in
   what is intended to be a technical spec.

9. Definition of IP Traffic Offload in Sec 2.2 is lacking clarity in
the context of this I-D. It would be good to define what is meant by
IP Traffic offload in the 3GPP operator scenario.

10. Is this specification applicable to 3GPP network deployments only?

11. "The selectors that are delivered to the mobile access gateway can be
   used to classify the traffic, so it can be offloaded to the local
   access network. "

   What is the local access network?

12. "The details related to DHCP transactions, or Router
   Advertisements on the access link are not shown here."

   Are these part of the MN attachment to the MAG process?

13. Figure 2 can be improved

14. "This would not have no effect ..."

15. What happens to IPsec tunnel-mode encrypted traffic? The I-D does
not say anything about such traffic whether it can be offloaded.

16. There is not enough information about how the MAG or the LMA
decide which traffic to offload. There is some handwaving about
interacting with a policy server and the I-D says it is out of
scope. But it would be useful to understand more about how this is
expected to work. For example, how does the MAG choose the traffic
selectors?

17. Is the NAT co-located with the MAG?

18. What happens if the MAG and LMA are in different domains (visited
and home networks)? Is there an issue in such a scenario?

19. The bandwidth and characteristics of the connectivity at the
access network may be different from what is at the home network
(LMA). The performance and user experience may be degarded when the
traffic is offloaded via the access network. The end-user has no
awareness of the traffic being offloaded. How do you handle this
situation? 

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 24 May 2012 17:11:52 -0700

Thanks for the review.  Comments inline ..

> if anyone can understand what this document is specifying.

   This specification defines a mechanism and a related mobility option
   for carrying IPv4 Offload traffic selectors between a mobile access
   gateway and a local mobility anchor in a Proxy Mobile IPv6 domain.
   Based on the received offload flow selectors from the local mobility
   anchor, a mobile access gateway can enable offload traffic rule on
   the selected IPv4 flows.

This is a feature extension to an existing protocol. Its hard to provide the complete context in the Abstract. Its just stating the two peers LMA and MAG can negotiate an offload policy, so those offload support can be enabled.

> 2. What are "access technology domains"?

Ex: WLAN
Will clarify with examples

>   access network to which it is attached." ???? Rephrase.

Ok

> interface or a reference point?

reference pt. will reword it

> 5. "...is providing the needed protocol glue." Protocol glue for what?

will reword it

>   not imply that all traffic is routed back to the LMA, right?

Yes, the access network can assign an IP address. That is for IPv6 and assuming there is prefix coloring, or other mechanisms for the mobile to identify that local address. But, we already stated this document is for IPv4-only traffic offload support. There we don't have mechanisms to assign multiple IPv4 addresses over DHCPv4; we can only assign a single IPv4 address. So, that IPv4 address is either a local address, or the home address.

>   happens if such traffic does not have IP mobility support?

Traffic which does not require any services such as mobility, QoS or inline services … will add clarifying text

>   what is intended to be a technical spec.

Will reword it

> IP Traffic offload in the 3GPP operator scenario.

Per your other comment, will have minimal text on 3GPP terminology or usage.

> 10. Is this specification applicable to 3GPP network deployments only?

This is a feature in standard PMIPv6 architecture; we can leave it there

>   What is the local access network?

reworded to "access network"

>   Are these part of the MN attachment to the MAG process?

They are missing as they are not relevant to core part of the discussion. There is change on the MN-MAG interface, or to the address assignment procedures.
 Will add a statement covering that.

> 13. Figure 2 can be improved

Ok. Will try

> 14. "This would not have no effect …"

fixed, thanks

> not say anything about such traffic whether it can be offloaded.

IPsec Tunnel mode ESP is applied on the flows that are routed through the tunnel and is not applied on offloaded traffic. 

> expected to work. For example, how does the MAG choose the traffic

That is a operator policy decision. There is no hand waiving there, its a configuration option. Should the spec recommend a specific flow that needs to be offloaded ? Does DSMIP spec specific what flow needs to be assigned to what access ? The mechanism is only allowing a mechanism and the peers to negotiate offload policy.

> 17. Is the NAT co-located with the MAG?

The offloaded traffic flows have to NAT translated. If that NAT function is collocated on the MAG, or outside is a deployment option

> and home networks)? Is there an issue in such a scenario?

Per RFC 5213 definition, PMIPv6 is for local mobility, with the protocol signaling between two peers in the same domain.

> awareness of the traffic being offloaded. How do you handle this

That is the nature of offload. Traffic which does not require any services such as mobility are chosen for offload. Those offloaded flows are not assured for any SLA's from the home operator. The traffic treatment is based on the resources in the access network and that is the case for home routed traffic as well (on the MN to MAG path). With respect to end-user awareness, there is no awareness same as with any NAT deployment, NAT64, DSLite or any other approach, the end-user is not aware of such translation.

Thanks for the review comments.

Sri

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

---

From: <[email-masked]>
Date: Fri, 25 May 2012 20:05:17 +0000

Inline:

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 24, 2012 7:11 PM
To: Basavaraj Patil <[email-masked]<mailto:[email-masked]>>
Cc: Netext <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netext] Review of I-D draft-ietf-netext-pmipv6-sipto-option

On May 24, 2012, at 3:19 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Raj> So you expect the user to know what offload means? The term "IPv4 offload traffic selectors" or "enable offload traffic" are used without setting the context.

Ex: WLAN

Ok

will reword it

Raj> Agree.

Raj> How does the MAG/LMA or policy server determine if traffic is considered essential? How do these elements know whether that application which is generating the traffic needs mobility, QoS etc. or not? As an example, a user could be streaming some video over HTTP. If the policy says that HTTP traffic can be offloaded, that application will suffer a break in session continuity. How do you deal with such a scenario? The session would be uninterrupted if it was not offloaded.

Will reword it

Raj> I would even suggest that instead of using the term offload, you could say something like traffic breakout at the MAG.

Raj> The I-D implies applicability to 3GPP network deployments (as you can see from the intro section) as well as the use of terms like PCRF, S2a etc. If you want to make it a generic capability of PMIP6, then you need to clean up the text accordingly.
11. "The selectors that are delivered to the mobile access gateway can be
  used to classify the traffic, so it can be offloaded to the local
  access network. "

Raj> What is the MN-MAG interface change that you are referring to? I thought there is no interaction with the MN in this spec.

Ok. Will try

fixed, thanks

Raj> Hmmm… Not sure I understand your comment above. Are you saying that offloading is not applicable to such Ipsec traffic? If so, please state in the I-D.

Raj> The comparison with DSMIP6 spec is invalid. The MN in the case of DSMIP6 makes the decision of which traffic/flow to switch from one interface to another. It is an MN decision. In this case, the network and some policy store is making the decision. So the question is : What is the basis for such a decision? Because the MN/user has no awareness of the traffic being shunted off via another access network.

Raj> If the NAT is not collocated with the MAG, do you have another tunnel to the NAT?

Raj> So are you saying that the MAG/LMA are always in the same domain? There is no roaming (between operators) possibility with PMIP6?

Raj> I still have a problem with the comment about the network/operator deciding unilaterally about whether certain traffic needs a capability like mobility or not.

-Raj

Sri

-Raj

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

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 25 May 2012 13:35:23 -0700

Thanks ..inline ..

On May 25, 2012, at 1:05 PM, <[email-masked]> <[email-masked]> wrote:

> 
> Inline: 
> 
> From: Sri Gundavelli <[email-masked]>
> To: Basavaraj Patil <[email-masked]>
> Cc: Netext <[email-masked]>, "[email-masked]" <[email-masked]>

Please suggest some text. I don think I can write an Abstract without using any technical terms. Offload is a generic term known to the mobile community. The target audience for this spec is a developer working in this field and I'd expect them to know this term. We can add explanation in the terminology section.

> Raj> How does the MAG/LMA or policy server determine if traffic is considered essential? How do these elements know whether that application which is generating the traffic needs mobility, QoS etc.…

Operator enables some firewall policy and blocks the traffic, what will the user do ? Operator enabling this firewall policy or the Offload policy should have the same considerations. 

> Raj> I would even suggest that instead of using the term offload, you could say something like traffic breakout at the MAG. 

Will reword the text to explain this more clearly

> Raj> The I-D implies applicability to 3GPP network deployments (as you can see from the intro section) as well as the use of terms like PCRF, S2a etc. If you want to make it a generic capability of…

Ok, 3GPP is just an example

> Raj> What is the MN-MAG interface change that you are referring to? I thought there is no interaction with the MN in this spec.

typo .."there is no change"

> Raj> Hmmm… Not sure I understand your comment above. Are you saying that offloading is not applicable to such Ipsec traffic? If so, please state in the I-D.

The tunnel mode ESP is on the MAG - LMA tunnel. The MAG splits the traffic, some traffic go out the gateway and some go through the tunnel. The tunneled traffic gets ESP policy.
If you are referring to the IPsec traffic from the UE, yes, its not applicable; sure, we can add that note explicitly. Thanks

> Raj> The comparison with DSMIP6 spec is invalid. The MN in the case of DSMIP6 makes the decision of which traffic/flow to switch from one interface to another. It is an MN decision. In this case, t…

This goes back to the previous discussion point of MN awareness

> Raj> If the NAT is not collocated with the MAG, do you have another tunnel to the NAT?    

Why do we need a tunnel ? For private IP conflict ? Depends on the topology of the network. If the operator wants to hide this traffic from the access network, the NAT function can be collocated on the gateway, or routed using some VLAN to the NAT gateway. We can add this consideration on this.

> Raj> So are you saying that the MAG/LMA are always in the same domain? There is no roaming (between operators) possibility with PMIP6?

They are always in the same PMIPv6 domain. Roaming is within a local mobility domain.

> Raj> I still have a problem with the comment about the network/operator deciding unilaterally about whether certain traffic needs a capability like mobility or not.

This relates to the previous discussion point.
This is a network-based solution. What can we do to tell the terminal ? This is the same consideration as the case of NAT64, MN is not aware of his traffic getting NAT'd out. 

Sri