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

[Sri Gundavelli <[e-mail]>]

Hi Yokota-san,

Thanks for your review. Please see inline.



On 2/5/12 12:01 AM, "Hidetoshi Yokota" <[e-mail]> wrote:

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

OK. Will rephrase it.

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

This is a good discussion point. The way I see it, any time, an IP flow that
uses the home address is directly offloaded into the access network, there
are two aspects to it:

#a: The offloaded traffic may be for a local destination within the access
network
#b: It may be for a destination in the Internet, outside the access network

In both these cases, depending on the location of the MAG, there may or may
not be NAT translation required for that flow. If its for Internet, NAT
translation is needed, for topological correctness, and is also a MUST if
the CN is not directly connected to the MAG and if that MAG is not an
higher-level aggregation router, where all the traffic goes through that
node. These are the different possible offload cases.

So, for case #a, specifically if the CN is directly attached to the MAG,
this may appear as a case of route optimization, but that is one specific
case in the list of offload cases and also the reason for offload is not
exactly for RO, but more policy driven.

I can fix the diagram to avoid any confusion.



 
> [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"
> 

Ok.


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

The spec does allow the option to be carried in both the directions. When
carried from MAG to LMA, its up to the LMA to accept or override the
request. I will clarify this bullet point.


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

The traffic selector is always specific to the flows associated with a
mobility session. This is an implicit assumption. This is a good comment, we
are probably missing one consideration there. When the selectors are based
on source address of the IP flow, the related assumptions have to be stated.
We Will clarify that part. This is a good catch.

Thanks again for your review.

Regards
Sri




 
> Regards,