Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt
Sri Gundavelli <sgundave@cisco.com> Tue, 31 January 2012 05:43 UTC
Return-Path: <sgundave@cisco.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EEB11E80FD for <netext@ietfa.amsl.com>; Mon, 30 Jan 2012 21:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.404
X-Spam-Level:
X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOJDowP0ST+W for <netext@ietfa.amsl.com>; Mon, 30 Jan 2012 21:43:01 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8B21F8712 for <netext@ietf.org>; Mon, 30 Jan 2012 21:43:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=21446; q=dns/txt; s=iport; t=1327988581; x=1329198181; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=pbj1IzW50S80r6sm5WA1NWshoxhJEl21FZeuSd6Uc9k=; b=kW7+cBlTLIj4DrkJyY8uDRA//UrCGlSX4SmzlgLHgfukhXOyDuYNmAVY PfX1OgAoJ4RPo8ZnZ9zuWAt6H6v05p5hNYKvLJkOP+IwKAjI+GBxCsmmI fRBPrHqXNjlXFufVM6eZICWjnJkjgURJAbN1RYu1Zs6uy9+FJgqJ8X1Sk w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIR+J0+rRDoI/2dsb2JhbAA5Cq5kgQWBcgEBAQMBAQEBDwEUEwIBMRAHBgEIEQEDAQEBJy4fAwYIAQEEARIbB4daCZo/AZ5TBIgXgmsBKRMBCAUDAwkHAQcHAoQtg1gEiECMXpJz
X-IronPort-AV: E=Sophos;i="4.71,594,1320624000"; d="scan'208";a="27738956"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 31 Jan 2012 05:43:00 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0V5h0Na026754; Tue, 31 Jan 2012 05:43:00 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 21:43:00 -0800
Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Jan 2012 05:43:00 +0000
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 30 Jan 2012 21:42:58 -0800
From: Sri Gundavelli <sgundave@cisco.com>
To: Ahmad Muhanna <ahmad.muhanna@ericsson.com>, "netext@ietf.org" <netext@ietf.org>
Message-ID: <CB4CBF62.38CF4%sgundave@cisco.com>
Thread-Topic: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt
Thread-Index: Aczc0ROglE/CDUTBRuW75YlYxAYO1gCl2l/QABG8c3wACCXgcAACyloY
In-Reply-To: <1FCAE7B6027FE3489B8497A060C704C4443BE188D4@EUSAACMS0714.eamcs.ericsson.se>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 31 Jan 2012 05:43:00.0682 (UTC) FILETIME=[316ADAA0:01CCDFDB]
Subject: Re: [netext] Review of ID: draft-ietf-netext-pmipv6-sipto-option-01.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2012 05:43:04 -0000
Hi Ahmad, Thanks. I will fix that text. Thanks for the review. Regards Sri On 1/30/12 8:28 PM, "Ahmad Muhanna" <ahmad.muhanna@ericsson.com> wrote: > Thanks Sri. > > Just one minor follow-up: > >> The mobility access >> [Ahmad-14] >> What the mobility access means here? is that a term that is defined >> somewhere? >> > > > You meant "mobility session" ? Its defined in the base spec. Let me add a > reference. > > [Ahmad] > Hmmmm; it seems that there is a "gateway" word missing. > The original text below. > > > " > > The mobility access > upon accepting the Proxy Binding Acknowledgement message MUST NOT > enable any offload policy for that mobility session. All the > mobile node's IP flows MUST be tunneled back to the local mobility > anchor. > " > > Thanks Sri for the quick reply. > > Regards, > Ahmad > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Monday, January 30, 2012 6:30 PM > To: Ahmad Muhanna; netext@ietf.org > Subject: Re: [netext] Review of ID: > draft-ietf-netext-pmipv6-sipto-option-01.txt > > Hi Ahmad, > > Thanks for the review. Please see inline. > > > > On 1/30/12 8:19 AM, "Ahmad Muhanna" <ahmad.muhanna@ericsson.com> wrote: > >> Hello, >> >> Please find my review comments for Rev 01 of the I-D >> (draft-ietf-netext-pmipv6-sipto-option) below: >> >> >> I have mainly editorial comments that need clarification and a couple >> of minor technical ones below. >> >> Regards, >> Ahmad >> >>>>>>> >> >> 1. Introduction >> >> 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. >> [Ahmad-01] >> why we are using S2/a rather than S2a? >> > > Yes, it should be s2a. > > >> [Ahmad-02] >> Please replace 'is providing' with 'provides' >> > > Ok > >> 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. >> >> [Ahmad-03] >> when Proxy Mobile IPv6 protocol [RFC5213] is used on this interface, >> the mobile node ... >> >> [Ahmad-04] >> Is it "anchored on" or "anchored at"? >> > > I can rephrase. > > >> 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. >> >> However, with the exponential growth in the mobile data traffic, >> mobile operators are exploring new ways to offload some of the IP >> traffic flows at the nearest access edge where ever there is an >> internet peering point, as supposed to carrying it all the way to the >> mobility anchor in the home network. Not all IP traffic needs 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. This approach provides >> greater leverage and efficient usage of the mobile packet core with >> increased overall network capacity and by lowering transport costs. >> >> [Ahmad-06] >> I have problem with the last sentence above... what are we trying to say? >> > Without offload, all the user plane traffic is going through the PGW. With the > approach specified in this document, some of the non-essential traffic can be > offloaded at the access edge, as supposed to carrying it through EPC. > In essence this results in: > > - Efficient usage of the packet core; by virtue or carrying select traffic > - Lowers the transport cost; if the packet core is considered as a premium > resource and using it only for select traffic and offloading all the other > traffic through the cheaper access, say WLAN. > > > >> May be something like follows: >> "With increased overall network capacity, this approach provides >> greater leverage and efficient usage of the mobile packet core which >> help lowering transport cost" Hope it makes it read better! :-) >> > > Ok. I can rephrase the text. > > >> >> The local mobility anchor in the home network can potentially deliver >> the IP flow selectors to the mobile access gateway in the access >> network, for identifying the IP flows that needs to be offloaded. >> >> This document defines a new mobility option, IP Traffic Offload >> Selector option for Proxy Mobile IPv6 (PMIPv6). This option can be >> used by the local mobility anchor for notifying the flow selectors >> for that can be used by the local mobility anchor for notifying the >> mobile access gateway flows that can be offloaded at the access edge. >> >> [Ahmad-07] >> This is a little confusing; sounds as if the notification goes to the >> flow selectors. What about? >> "This option can be used by the local mobility anchor to notify the >> mobile access gateway with the flow selectors that can be offloaded at >> the access edge." >> > > Ok. I can rephrase it. > > >> >> Since, the mobile node's IP address topologically belongs to the home >> network, the offloaded IP traffic flows need to be NAT [RFC2663] >> translated. Given this NAT translation requirement for the offloaded >> traffic, this approach will be limited to mobile node's IPv4 flows. >> >> There are better ways to solve this problem for IPv6 and with the >> goal not to create NAT66 requirement, [Ahmad-08] Can we remove the >> above sentence? and start the sentence with the following portion. >> > > Well, the scope of the document is only for IPv4. If we say it applies for > IPv6 user flows, we need a NAT66 gateway. I'm not sure, chairs will agree :), > Raj made sure we put this line. > > > >> This specification does not >> support traffic offload support for IPv6 flows. This document also >> does not define any new semantics for flow selectors. The flow >> identification and the related semantics are all leveraged from >> [RFC6088]. >> >> >> 2. Conventions and Terminology >> >> 2.1. Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> 2.2. Terminology >> >> All the mobility related terms used in this document are to be >> interpreted as defined in the base Proxy Mobile IPv6 specifications >> [RFC5213] and [RFC5844]. Additionally, this document uses the >> following abbreviations: >> >> IP Flow >> >> IP Flow represents a set of IP packets that match a traffic >> selector. The selector is typically based on the source IP >> address, destination IP address, source port, destination port and >> other fields in upper layer headers. >> >> 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. >> >> NAT (Network Address Translation) >> >> Network Address Translation [RFC2663] is a method by which IP >> addresses are mapped from one address realm to another, providing >> transparent routing to end hosts. >> [Ahmad-09] >> Do we need to include this terminology? >> > > True. May be its too obvious. Can get rid of that. Fine, either way. > > > >> >> 3. Solution Overview >> >> 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. For example, all >> the HTTP flows may be be offloaded at the mobile access gateway and >> all the other flows for that mobility session are tunneled back to >> the local mobility anchor. >> >> >> >> >> _----_ >> _( )_ >> ( Internet ) >> (_ _) >> '----' >> | >> (IPv4 Traffic Offload Point >> at access edge gateway for >> non-essential traffic >> Ex: HTTP Traffic Offloaded) >> | >> ...................................................... >> | . +----------------+ >> +---+ . | Operator Value | >> |NAT| . | Added Services | >> +---+ . +----------------+ >> | _----_ | >> +-----+ _( )_ +-----+ >> [MN]----| MAG |======( IP )======| LMA |-- Internet >> +-----+ (_ _) +-----+ >> '----' ( >> . >> . >> . >> [Access Network] . [Home Network] >> ...................................................... >> >> Figure 1: Access Networks attached to MAG >> >> >> >> 3.1. LMA Considerations >> >> The following considerations apply to the local mobility anchor and >> the mobile access gateway. >> [Ahmad-10] >> Is this a common section then? >> > > Oops. Copy paste error. The explanation needs to go to the main section. > Thanks for pointing this. > > > >> Figure 1 explains the operational sequence of the IP Traffic Offload >> selectors between the mobile access gateway and the local mobility >> anchor. >> >> >> 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. IPv4 packet from mobile node >> | | | 7. Forwarding rule - Tunnel home/offload >> | | | >> >> >> >> Figure 2: Exchange of IP Traffic Offload Selectors >> >> o 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. This would not have no effect on the >> operation of the rest of the protocol. >> >> o 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. >> [Ahmad-11] >> Why NOT use the following: "the local mobility anchor (identify/or >> acquire) the traffic selectors based on.... This will encompass the >> possibility for the LMA to receive the offload policy via a different >> infrastructure node, e.g., PCRF. Just a suggestion. >> > > That's a good point. The policy can come from PCRF. Sure. > > > >> However, if >> the received Proxy Binding Update included a proposed Offload >> traffic selectors, the local mobility anchor MAY choose to honor >> that request and include the proposed selectors in the reply. >> >> 3.2. MAG Considerations >> >> o If the configuration variable, EnableIPTrafficOffloadSupport on >> the mobile access gateway is set to a value of (0), then the >> mobile access gateway MUST NOT include the IP Traffic Offload >> Selector Option Section 4 in the Proxy Binding Update message that >> it sends to the local mobility anchor. Otherwise, the option MUST >> be included in the Proxy Binding Update message. >> >> When this option >> is included, it is an indication to the local mobility anchor that >> the mobile access gateway is capable of supporting IP Traffic >> Offload support. The TS format field of the IP Traffic Offload >> >> [Ahmad-12] >> Have we defined what TS before now? >> > > Will add a reference to the later section, where its defined. > > > > > >> Selector Option MUST be set to a value of (0), indicating that the >> mobile access gateway is not proposing any specific offload policy >> for that mobility session, but a request to the local mobility >> anchor to provide the IP traffic offload flow selectors for that >> mobility session. >> >> o The mobility access gateway MAY choose to include its proposed IP >> traffic offload flow selectors in the IP Traffic Offload Selector >> Option Section 4. Including this offload traffic spec serves as >> a [Ahmad-13] "Including this offload traffic selectors serves ..." >> > > Ok. > > >> proposal to the local mobility anchor, which the local mobility >> anchor can override with its own offload policy, or agree to the >> proposed policy. When including the offload traffic selectors, >> the TS format field of the IP Traffic Offload Selector Option MUST >> be set to the respective flow specification type. >> >> o If there is no IP Traffic Offload Selector Option in the >> corresponding Proxy Binding Acknowledgement message, that the >> mobile access gateway receives in response to a Proxy Binding >> Update, it serves as an indication that the local mobility anchor >> does not support IP Traffic Offload support for that mobility >> session, and it implies the local mobility anchor cannot deliver >> IP flow selectors for that mobility session. >> >> The mobility access >> [Ahmad-14] >> What the mobility access means here? is that a term that is defined >> somewhere? >> > > > You meant "mobility session" ? Its defined in the base spec. Let me add a > reference. > > > >> upon accepting the Proxy Binding Acknowledgement message MUST NOT >> enable any offload policy for that mobility session. All the >> mobile node's IP flows MUST be tunneled back to the local mobility >> anchor. >> >> o If there is IP Traffic Offload Selector Option in the >> corresponding Proxy Binding Acknowledgement message, it is an >> indication that the local mobility anchor has provided the IP >> traffic Offload selectors for that mobility session and the >> identified IP flows have to be offloaded. Considerations related >> to (M) flag MUST be applied. >> [Ahmad-15] >> what about MAG handling of the TS option in BA when the MAG has not sent it >> in >> the BU? I believe this is a valid scenario that needs to be addressed. >> >> > > So, we used TS as a means to notify the capability and also as a means to > exchange the offload flow selectors. If the capable of supporting SIPTO, it > can include this option and the LMA can deliver the offload flow selectors. > Now, if the MAG is not capable (Ex: a residential gateway withno scope for > offload, or have internet peering points), then it will not include the TS > and the LMA will not deliver those selectors. But, there is also the other > question which you are pointing too. Should the LMA notify the offload flow > selectors dynamically, this is an open question. > > >> >> 4. IP Traffic Offload Selector Option >> >> A new mobility option, IP Traffic Offload Selector option, is defined >> for using it in Proxy Binding Update (PBU) and Proxy Binding >> Acknowledgement (PBA) messages exchanged between a local mobility >> anchor and a mobile access gateway. >> >> [Ahmad-16] >> "A new mobility option, IP Traffic Offload Selector option, is defined >> for using it in Proxy Binding Update (PBU) and Proxy Binding >> Acknowledgement (PBA) messages exchanged between a mobile access gateway >> and a local mobility anchor." seems that the draft always mentions LMA first! >> :-) >> > > I can switch :) > >> >> This option is used for carrying >> the flow selectors for supporting IP traffic offload function at the >> mobile access gateway. >> [Ahmad-17] >> I think we should use the word enforcing/or enabling rather than supporting >> for the sentence to read as follows: >> "This option is used for carrying the flow selectors for enforcing/enabling >> IP >> traffic offload function at the mobile access gateway." >> > > OK. > >> >> The alignment requirement for this option is 4n. >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |M| Reserved | TS Format | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Traffic Selector ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure 3: IP Traffic Offload Selector Option >> >> >> Type >> <IANA-1> >> >> Length >> 8-bit unsigned integer indicating the length in octets of the >> option, excluding the type and length fields. >> >> Reserved >> [Ahmad-18] Insert line. >> This field is unused for now. The value MUST be >> initialized to 0 by the sender and MUST be ignored by the >> receiver. >> > > Ok. > > >> IP Traffic Offload Mode Flag >> [Ahmad-19] Insert line. >> > > Ok. > >> This field indicates the offload mode. >> If the (M) flag value is set to a value of (1), it is an >> indication that all the flows except the identified IP flow(s) in >> this mobility option needs to be offloaded at the mobile access >> gateway. 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. >> [Ahmad-20] >> We need to add >>some text<< under the MAG consideration to mention that >> despite the M flag value in the TS Option in the BU, the setting by the LMA >> in >> the BA overrides. something like that. >> > > Sure. This is a good point. We missed few considerations on the override > part. > > > >> TS Format >> [Ahmad-21] Insert line. >> > > Ok. > > >> 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]. >> [Ahmad-22] >> should not we mention that all other values are reserved? >> > > Sure > > >> TS Selector >> [Ahmad-23] Insert line. >> > > Sure > >> A variable-length opaque field for including the traffic >> specification identified by the TS format field. >> [Ahmad-24] >> Should not we say: " ... identified by the TS format field and the IP Traffic >> Offload Mode Flag" Just wondering. the key word here "identified" >> > > The selectors still apply for both the state values of the (M) flag. Its > more an inverse rule, if the identified traffic is offloaded, or if the > identified traffic is allowed to come in. > > > >> >> 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]. >> > > Thanks a lot Ahmad for the review. We will work on a revision. Let me know > if these comments address all the review comments. > > > Regards > Sri > > > >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >
- Re: [netext] Review of ID: draft-ietf-netext-pmip… Sri Gundavelli
- [netext] I-D Action: draft-ietf-netext-pmipv6-sip… internet-drafts
- [netext] Review of ID: draft-ietf-netext-pmipv6-s… Ahmad Muhanna
- Re: [netext] Review of ID: draft-ietf-netext-pmip… Sri Gundavelli
- Re: [netext] Review of ID: draft-ietf-netext-pmip… Ahmad Muhanna
- Re: [netext] Review of ID: draft-ietf-netext-pmip… Sri Gundavelli
- Re: [netext] Review of ID: draft-ietf-netext-pmip… pierrick.seite