Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt

[<[e-mail]>]

Hi,


Please find below my review of
draft-gundavelli-netext-pmipv6-sipto-option-01:

This document is in good shape and my comments are mainly editorial. My
main concern is that the introduction is focusing too much on the 3GPP
S2a use-case while the offload option could be useful in other type of
architectures. With the current text, the reader may think that the
offload option has been designed only for 3GPP/EPC. So, at least the
document should avoid using 3GPP specific terminology such as S2a and
SIPTO. But, what about this rewording for the intro:

------ OLD TEXT ------
Mobile Operators are expanding their network coverage by integrating
various access technology domains into a common IP mobile core.  For
providing IP mobility support to a mobile node irrespective of the
access network to which it is attached, the 3GPP S2/a Proxy Mobile IPv6
[TS23402] interface, specified by the 3GPP system architecture, is
providing the needed protocol glue.  When this protocol interface based
on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is topologically
anchored on the local mobility anchor [RFC5213] in the home network.
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.

---- NEW TEXT ----

In current IP mobility architecture, the mobile node is topologically
anchored on the mobility anchor in the home network. As a consequence,
the mobile node's IP traffic is always tunneled back to the mobility
anchor in the home network. However, some of the traffic does need
mobility support and, so, does not need to be anchored. Actually, in
this situation, routing can be easily optimized when using Proxy Mobile
IPv6 [RFC5213]: the mobile access gateway could forward this traffic to
the local Internet peering point instead of tunneling back to the local
mobility anchor. The 3GPP/Wi-Fi offloading use-case is a concrete
example of such an optimization. Indeed, mobile Operators are expanding
their network coverage by integrating various access technology domains
into a common IP mobile core.  For providing IP mobility support to a
mobile node irrespective of the access network to which it is attached,
a Proxy Mobile IPv6 interface, specified by the 3GPP system
architecture, is providing the needed protocol glue [TS23402].  



Other comments on the introduction:

---- OLD TEXT ------------
some of the non-essential traffic 
-----NEW TEXT --------
some of the traffic

Note: non-essential traffic sounds pejorative (for an conscientious
operator, there is no non-essential traffic :-)) while the goal is to
distinguish traffic which need mobility support from traffic which does
not... accessing mobile operator services (as depicted on figure 1) is
another use-case for PMIP but it is a specific usage for 3GPP/Wi-Fi
interworking, so I suggest to not refer to this use-case and focus on
mobility; so I've modified fig.1 (see below).

2.2 Terminology

I suggest to remove SIPTO acronym which a 3GPP terminology (it gives a
3GPP coloring to the document and it should be avoided IMHO). Moreover
SIPTO is not used in the rest of the document.


3. Solution Overview:


---- OLD TEXT ------------
The following illustrates the scenario where the mobile access gateway
in an access network having the ability to offload some of the IPv4
traffic flows, based on the traffic selectors it received from the local
mobility anchor in the home network.
-----NEW TEXT --------
The following illustrates the scenario where the mobile access gateway
has the ability to offload some of the IPv4 traffic flows, based on the
traffic selectors it received from the local mobility anchor in the home
network.

----- NEW PICTURE for figure 1 --------

         _----_
          _(      )_
         ( Internet )                 
          (_      _)                  
            '----'                    
              |                        +-----------------+

   (IPv4 Traffic Offload Point         | Services with   |              
    at access edge gateway for         | mobility support|
    offloaded traffic                  +-----------------+
    Ex: HTTP Traffic Offloaded)               |
              |                               |
   ...........................................|...........
              |               .               |
            +---+             .               |
            |NAT|             .               |
            +---+             .               |
              |            _----_             |
           +-----+       _(      )_       +-----+
   [MN]----| MAG |======(    IP    )======| LMA |-- Internet
           +-----+       (_      _)       +-----+
                           '----'      (
                              .
                              .
                              .
       [Access Network]       .        [Home Network]
   ......................................................



3.1 LMA considerations

------ OLD TEXT -------
The following considerations apply to the local mobility anchor and the
mobile access gateway.
------- NEW TEXT ---------
The following considerations apply to the local mobility anchor.

Inconsistency in Figure 2:

There are 6 operations in the sequence chart and 7 bullets: "7.
Forwarding rule - Tunnel home/offload" is not represented in the message
flow.

Moreover I think the DHCP OFFER/REQUEST and ACK messages should come
right after step #5. It'd lead to the following picture:

MN    MAG(NAT)   LMA
   |------>|        |    1. Mobile Node Attach
   |       |------->|    2. Proxy Binding Update
   |       |<-------|    3. Proxy Binding Acknowledgement (IPTS Option)
   |       |========|    4. Tunnel/Route Setup
   |       +        |    5. Installing the traffic offload rules
   |<----->|        |    6. DHCP OFFER/REQUEST/ACK exchange
   |------>|        |    7. IPv4 packet from mobile node
   |       +        |    8. Forwarding rule - Tunnel home/offload
   |       |        |

------ OLD TEXT -------
If the received Proxy Binding Update includes the IP Traffic
      Offload Selector Option Section 4, but if the configuration
      variable, EnableIPTrafficOffloadSupport on the local mobility
      anchor is set to a value of (0), then the local mobility anchor
      MUST ignore the IP Traffic Offload Selector Option and process the
      rest of the packet.
------- NEW TEXT ---------
If the received Proxy Binding Update includes the IP Traffic
      Offload Selector Option Section 4, but if the configuration
      variable, EnableIPTrafficOffloadSupport (Section 6) on the local
mobility
      anchor is set to a value of (0), then the local mobility anchor
      MUST ignore the IP Traffic Offload Selector Option and process the
      rest of the packet as per [RFC5213].

------ OLD TEXT -------
If the received Proxy Binding Update includes the IP Traffic
      Offload Selector Option Section 4, and if the configuration
      variable, EnableIPTrafficOffloadSupport on the local mobility
      anchor is set to a value of (1) , then the local mobility anchor
      can construct the traffic selectors based on the offload policy
      and deliver those selectors in the Proxy Binding Acknowledgement
      message using the IP Traffic Offload Selector Option.
------- NEW TEXT ---------
If the received Proxy Binding Update includes the IP Traffic
      Offload Selector Option (Section 4), and if the configuration
      variable, EnableIPTrafficOffloadSupport (Section 6) on the local
mobility
      anchor is set to a value of (1) , then the local mobility anchor
      can construct the traffic selectors based on the offload policy 
      and deliver those selectors in the Proxy Binding Acknowledgement
      message using the IP Traffic Offload Selector Option. How to
provision offload policy on the local mobility anchor is out of the
scope of that document.

What about adding the following LMA operation?:

If the received Proxy Binding Update does not include the IP Traffic
Offload Selector Option (Section 4), and if the configuration variable,
EnableIPTrafficOffloadSupport (Section 6) on the local mobility anchor
is set to a value of (1), then the local mobility anchor SHOULD not
include the IP Traffic Offload Selector Option in the Proxy Binding
Acknowledgement.

3.2 MAG considerations

Second bullet: replace "mobility access gateway" by "mobile access
gateway" 

--- OLD TEXT ----
The mobility access upon accepting the Proxy Binding Acknowledgement
message MUST NOT enable any offload policy for that mobility session.
--- NEW TEXT ----
The mobile access gateway upon accepting the Proxy Binding
Acknowledgement message MUST NOT enable any offload policy for that
mobility session.

Is the following operation covered (Though, I'm not sure it does make
sense) ? : If there is IP Traffic Offload Selector Option without
selector in the corresponding Proxy Binding Acknowledgement message, the
mobile access gateway SHOULD apply its policy.

4. IP Traffic Offload Selector Option

For a better readability: insert carriage return after "Reserverd", "IP
Traffic Offload Mode Flag", "TS Format" and "TS Selector".


---- OLD TEXT ------
If the (M) flag value is set to a value of (0), it is an indication that
the identified IP flow(s) needs to be offloaded at the mobile access
gateway and all other IP flows associated with  that mobility session
needs to be tunneled to the local mobility  anchor.
---- NEW TEXT ---------
If the (M) flag value is set to a value of (0), it is an indication that
the identified IP flow(s) must be offloaded at the mobile access gateway
and all other IP flows associated with that mobility session need to be
tunneled to the local mobility anchor.


---- OLD TEXT ------
TS Format  
An 8-bit unsigned integer indicating the Traffic Selector Format.  The
value of "0" is reserved and is used when there are no selectors to
carry, relevant when the option is used as a capability indicator.  The
value of (1) is assigned for IPv4 Binary Traffic Selector [RFC6088].

---- NEW TEXT ---------
TS Format  
An 8-bit unsigned integer indicating the Traffic Selector Format.  The
value of "0" is reserved and is used when there are no selectors to
carry. In this case, the option is used only as a capability indicator.
When the value of TS Format field is set to (1), the format that follows
is the IPv4 Binary Traffic Selector specified in section 3.1 of
[RFC6088].


---- OLD TEXT ------
TS Selector  
A variable-length opaque field for including the traffic specification
identified by the TS format field.  When the value of TS Format field is
set to (1), the format that follows is the IPv4 Binary Traffic Selector
specified in section 3.1 of [RFC6088].
---- NEW TEXT ---------
TS Selector  
A variable-length opaque field for including the traffic specification
identified by the TS format field.  [the rest is already in description
of TS format]


6. Protocol Configuration Variables

--- OLD TEXT ----
it MUST include the IP Traffic Offload Selector option in the Proxy
Binding Update messages and offload the negotiated IP flows to the
access network.
---- NEW TEXT ----
it MUST include the IP Traffic Offload Selector option in the Proxy
Binding Update messages and offload the negotiated IP flows to the
nearest Internet peering point.


7. Security Considerations

Just for discussion:

Allowing the MAG to provide its policy may induce a security risk: IMU,
the MAG is a more vulnerable than the LMA. For instance, if the MAG is
in a residential gateway, there is a risk for that MAG to be corrupted.
If so, the MAG may provide corrupted offloading policy to the LMA which
has no way to check the policy. Of course this is out of scope of
securing PMIP signaling but maybe we could stress the requirement for a
secured policy provisioning mechanism...


Hope that helps,
BR,
Pierrick