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

[Sri Gundavelli <[e-mail]>]

Hi Pierrick,

Thanks for your review. Please see inline.




On 2/1/12 4:09 AM, "[e-mail]" <[e-mail]>
wrote:

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


I agree with that. It was more an example. I can reword it.



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

Thanks for the text. Appreciated. Structuring along these lines makes sense.
Let me use it and rework it a bit.


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

Ok. Good point. 


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

Yes. I did try to stay away from that term, some how ended up using it one
place by error. Will fix it and stay away from the 3GPP color :)



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


OK. 


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

So, the change is on the "Operator Value added services" to "Services with
mobility support". Sure. Makes lot of sense.

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

Ok


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

I represented the state creation as an operation and hence the mismatch. Let
me clarify that.
 
> Moreover I think the DHCP OFFER/REQUEST and ACK messages should come
> right after step #5. It'd lead to the following picture:
> 

Yes. I agree, for completeness, I can put some dotted lines after Step-1 and
Step-3. 


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

OK

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

OK. I thought I covered this point. But, I will use this text and
consolidate.



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

Good point. Ack. Thanks.


> 3.2 MAG considerations
> 
> Second bullet: replace "mobility access gateway" by "mobile access
> gateway" 
>

Yep. Its fixed in -02.

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

Yep. Its fixed in -02.



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

I thought about this. If we go with the assumption that the MAG needs to
indicate its capability, this may not do good for MAG. Else, we remove the
capability concept and allow LMA always send the offload spec. Or, we can
simply state, MAG should ignore the option, if it got the TS spec, when it
never included the option in the PBU.




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

Sure. Its fixed in -02.


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

OK


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


Much better. OK.



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

Ok.



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

Well, it can be for local access as well. As long as the NAT requirement is
met, the traffic need not always hit the internet peering point. In many
use-cases I've seen, its for local service access. Say a wireless subscriber
is using wire line access from the same operator, for local service access
(Ex: content) within the wireline network, and all the rest of the traffic
comes back. But, the offloaded traffic never hits internet.




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

This is a good  comment. But, the MAG always has the control on the traffic
offload. If its a compromised node, it can just offload every thing. We can
see if there are additional security considerations to be added.

Thanks for the review Pierrick. This really helps. Appreciated !!!

Regards
Sri




> Hope that helps,
> BR,
> Pierrick
> 
>