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

[<[e-mail]>]

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