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

[Sri Gundavelli <[e-mail]>]

Thanks for the review.  Comments inline ..



On May 24, 2012, at 3:19 PM, <[e-mail]> <[e-mail]> wrote:

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


   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


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

Ok

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

reference pt. will reword it


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

will reword it


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

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.


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

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


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

Will reword it


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

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


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

reworded to "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?
> 

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



> 15. What happens to IPsec tunnel-mode encrypted traffic? The I-D does
> 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. 



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

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


    

> 18. What happens if the MAG and LMA are in different domains (visited
> 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.



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


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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext