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
>