[netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-03

[Hidetoshi Yokota <[e-mail]>]

Hi Sri,

Good work. Here are my comments and suggestions for version -03:

[Section 2.2]

   Selective IP Traffic Offload (SIPTO)

      The approach of selecting specific IP flows and routing them to
      the local network, as supposed to tunneling them to the home
      network.           ^^^^^^^^^^^^^^

"as opposed to" ?

Also, the box entitled with "Local Services" in Figure 1 is a bit
confusing because this doesn't seem to be related to "traffic offload".
It is ok if you use it for route optimization, but for an example of
traffic offload, this box may not be necessary.

[Section 3]

The following caption does not seem to express the whole figure:

 Figure 1: Access Networks attached to MAG

Suggested one is like:
"Network configuration/architecture where traffic offloading is applicable"

[Section 3.1]

My general comment is that it is not very clear if the traffic offload
selector is provided by the LMA or can be done by the MAG as well.
According to Section 3 and Figure 2, the traffic offload selector comes
from the LMA to the MAG, so the first bullet of Section 3.1 is a little
bit confusing. If this spec allows the MAG to send the IPTS option, such
scenario should also be included in Section 3 and #2 of Figure 2

   |       |------->|    2. Proxy Binding Update (IPTS Option)
                                                 ^^^^^^^^^^^^^^
[Q] If the MAG can also send this option, I have one question: when the
MN's IPv4 address is assigned by the LMA, the MAG may not be able to
know that address until it receives the PBA with that address from the
LMA. In that case, the MAG cannot create a valid traffic offload
selector, which requires the MN's IPv4 address. I guess the PBU/PBA need
to be exchanged multiple times. If the traffic offload selector is
provided only by the LMA, the scenario will be simpler. I recommend
clarifying possible scenarios and procedures.

Regards,
-- 
Hidetoshi