From jxyswallow@gmail.com Wed Apr 7 20:41:21 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E203A67BD for ; Wed, 7 Apr 2010 20:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeyg8hLTTrEr for ; Wed, 7 Apr 2010 20:41:18 -0700 (PDT) Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by core3.amsl.com (Postfix) with ESMTP id 611F63A67A5 for ; Wed, 7 Apr 2010 20:41:18 -0700 (PDT) Received: by pzk11 with SMTP id 11so43656pzk.32 for ; Wed, 07 Apr 2010 20:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:cc:content-type; bh=c44/MGe2hoRIus+dQEwwEznlqzNNFf/0MDV44egy4+k=; b=LaTUuj+MwueJIOudWD9a4ky7V9vxddCnK4qR/hb8BNNWxF1610uQqb5pBQ70dr6VXj 8jIpJQ+Rm7rYu7MRTIl1nwJ75P/0hmX3drrL/BmWcr4Eu39lFCgp1NLoZ/FJpWfQ65Va jumzA1pLkyvRxlA+pvGIMZUBBLmqHxOHW4Z+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=uG/c/iO7/oO8BoN372wvuyzWVseDeWbfKf8sYFt+M1LVTWN1IJJPNnRyvUzIjtJf0m sHtQ36U1BGT16zB36nGY10Cd5etCSc3uRAy4PX+JrYsRKK5YyfD6gWoriTy2+8LpnGtC aW4GhaLP185gb6ymntSbrSWatY153FDwuqnw0= MIME-Version: 1.0 Received: by 10.142.11.4 with HTTP; Wed, 7 Apr 2010 20:41:12 -0700 (PDT) Date: Thu, 8 Apr 2010 11:41:12 +0800 Received: by 10.142.209.5 with SMTP id h5mr4142819wfg.85.1270698072794; Wed, 07 Apr 2010 20:41:12 -0700 (PDT) Message-ID: From: Xiaoyan Jiang To: hkzhang@bjtu.edu.cn Content-Type: multipart/alternative; boundary=000e0cd32c7c3ee5fc0483b17352 Cc: netext@ietf.org Subject: Re: [netext] draft-zhang-netext-ao-mulif-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 03:41:21 -0000 --000e0cd32c7c3ee5fc0483b17352 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello Zhang=A3=BA I have read draft-zhang-netext-ao-mulif-00 and have some questions t= o ask. In RFC 5213, it is specified that LMA will delete the binding cache entry after it waits for a certain amount of time when that interface detaches. When the inter-technology handover happens,there i= s only the binding entry(s) for the active interface of that MN in LMA. What does it mean to indicate LMA the new IFP settings? Thanks Xiaoyan Jiang --000e0cd32c7c3ee5fc0483b17352 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello Zhang=A3=BA
  
       = I have read draft-zhang-netext-ao-mulif-00 and have some questions to ask. In RFC 5213, it is specified that LMA will delete
 the binding cache entry after it waits for a certain amount of time when that interface detaches. When the inter-technology handover happens,there is only the binding entry(s) for the active interface of that MN in LMA. What does it mean to indicate LMA the new IFP settings?

  Thanks

Xiaoyan Jiang --000e0cd32c7c3ee5fc0483b17352-- From sunseawq@huawei.com Wed Apr 14 19:49:17 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3C328C0F6 for ; Wed, 14 Apr 2010 19:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.043 X-Spam-Level: * X-Spam-Status: No, score=1.043 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geJRzDzWcX45 for ; Wed, 14 Apr 2010 19:49:15 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 34B2628C113 for ; Wed, 14 Apr 2010 19:49:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W00CKRD5US2@szxga03-in.huawei.com> for netext@ietf.org; Thu, 15 Apr 2010 10:49:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W0081SD5U15@szxga03-in.huawei.com> for netext@ietf.org; Thu, 15 Apr 2010 10:49:06 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0W00J89D5OWR@szxml04-in.huawei.com> for netext@ietf.org; Thu, 15 Apr 2010 10:49:06 +0800 (CST) Date: Thu, 15 Apr 2010 10:49:00 +0800 From: Qin Wu To: netext@ietf.org Message-id: <002801cadc46$369ef910$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_an4dooirHfeIj3v2SBmyzg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [netext] Review of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 02:49:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_an4dooirHfeIj3v2SBmyzg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, In Anaheim I volunteered to review this I-D. I think this I-D has been in good shape. Here is my review of redirection document. --------------------------------------------------------------------------------------------------------------------------------- In the section 1: o LMAs with multiple IP addresses: a cluster of LMAs or a blade architecture LMA may appear to the routing system as multiple LMAs with separate unicast IP addresses. A MAG can initially select any of those LMA IP addresses as the LMA Address using e.g., DNS- and AAA-based solutions. However, MAG's initial selection may be suboptimal from the LMA point of view and immediate redirection to a "proper LMA" would be needed. The LMA could use [RFC5142] based approach but that would imply unnecessary setting up of a mobility session in a "wrong LMA" with associated backend support system interactions, involve additional signaling between the MAG and the LMA, and re-establishing mobility session to the new LMA again with associated signaling. [Qin]: As described in [RFC5142], it seems changing the home agent of mobile node is mainly becos load balance consideration or overloaded factor. Therefore not sure whether the bullet one(LMAs with multiple IP address) overlaps with bulltet two(Bypassing a load balancer). [Qin] In the section 5.4, it mentioned that Mobility Session can be Created After the Redirection. Not sure whether additional signaling between the MAG and the redirected LMA is required? o Independence from DNS: DNS-based load balancing is a common practise. However, keeping MAGs up-to-date with LMA load status using DNS is hard e.g., due caching and unpredictable zone update delays. Generally, LMAs constantly updating [RFC2136] zone's master DNS server might not feasible in a large PMIPv6 domain due to increased load on the master DNS server and additional background signaling. Furthermore, MAGs may do (LMA) destination address selection decisions that are not in-line what the DNS administrator actually wanted [RFC3484]. [Qin]: Are you saying DNS-based LMA discovery is independent from runtime LMA assignment described in this document? In some cases, DNS-based LMA discovery may cost too much. Then we can choose runtime LMA assignment instead of DNS-based approach. If in this way, I am not really clear what the DNS-based load balancing is here? Are you saying we need tradeoff between DNS based approach and runtime LMA assignment? o Independence from AAA: AAA-based solutions have basically the same arguments as DNS-based solutions above. It is also typical that AAA-based solutions offload the initial LMA selection to the DNS infrastructure. The AAA infrastructure does not return an IP address or a Fully Qualified domain Name (FQDN) to a single LMA, rather a FQDN representing a group of LMAs. [Qin] It is better to have references to AAA based solution and DNS based solution. o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 specification does not specify how the PMIPv6 protocol should treat anycast addresses assigned to mobility agents. Although [RFC4291] now allows using anycast addresses as source addresses, it does not make much sense using anycast addresses for the MAG to the LMA communication after the initial PBU/PBA exchange. For example, a blade architecture LMA may appear to the routing system as multiple LMAs with separate unicast IP addresses and with one or more "grouping" anycast addresses. [Qin]: Not sure [RFC4291] allow using anycast address as source adresses or destination adress? [Qin]: I don't really understand what this paragraph want to deliver? The mechanism for Runtime LMA assignment does not support IPv6 anycast addressing? It seems this parpagraph is not the reason for using runtime assignment? am I right? In section 3: The LMA MUST NOT include the Redirect mobility option in the PBA and perform the redirection, unless the MAG indicated the redirection functionality support in the corresponding PBU using the Redirection- Capability mobility option. The LMA MUST NOT include the Redirect mobility option unsolicited even if the MAG had earlier indicated support for the redirection functionality. [Qin] It seems to me that this assumption is too strict. What if MAG and LMA have a prioor aggreement that MAG support Rediction functionality? In section 4.2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 r2LMA Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional IPv4 r2LMA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redirect Mobility Option o Option Type: 8-bit identifier set to TBD2. o Option Length: 8-bit unsigned integer, representing the length of the Redirect mobility option in octets, excluding the Option Type and Length fields. If the IPv4 LMA Address is included in the option, the Option Length MUST be set to 22. Otherwise, the Option Length MUST be set to 18. o Reserved: This field is reserved for future use. MUST be set to zero. o IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This value is present if the r2LMA IPv4 address is available. [Qin]: I think whether IPv4 r2LMA address is included depends on a) the r2LMA IPv4 address is available by rfLMA b) 'F'flag is set to 1 in the Redirect-Capability Mobility Option? what am I missing? In section 6: A MN can be multi-homed. A single LMA entity should have the control over all possible multi-homed mobility sessions the MN has. All mobility sessions a multi-homed MN may have SHOULD be anchored in the single LMA entity. Therefore, once the MN has established one mobility session with one LMA, the subsequent mobility sessions of the same MN SHOULD be anchored to the LMA that was initially assigned. [Qin]: Little confused here. If MN has changed from rfLMA to r2LMA, there are two choices ensuing : a) all the mobility sessions should be moved from rfLMA to r2LMA. b) all the mobility sessions will still stay at rfLMA? which one is correct? One possible solution already supported by this specification is applying the redirection only for the very first initial attach a multi-homed MN does towards a PMIPv6 domain. After the initial attach, the assigned r2LMA Address has been stored in the policy profile. For the subsequent mobility sessions of the multi-homed MN, the same assigned r2LMA Address would be used and there is no need to contact the rfLMA. [Qin]: What if r2LMA is overloaded again and need to rediret the mobility session to another new r2LMA? In Section 8: If a PMIPv6 domain deployment with a redirection requires that a rfLMA has to modify a received PBU in any way e.g., by changing the destination IP address field of the outer IP header, then the security mechanism (such as possible authentication options) used to protect the PBU must not cover the outer IP header on those parts that might get modified. Alternatively, the rfLMA can do all required security mechanism processing on the received PBU and remove those security related options from the PBU that would cause the security check to fail on the r2LMA. [Qin]: It seems to me changing the security part in the PBU is a big challenging to runtime assignment. So I think maybe it is simpler to add another outer IP header which may sacrifice some processing overheads at rfLMA. --Boundary_(ID_an4dooirHfeIj3v2SBmyzg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,
In Anaheim I volunteered to review this I-D. I think this I-D has been in good shape. Here is my review of redirection document.
---------------------------------------------------------------------------------------------------------------------------------
In the section 1:
   o  LMAs with multiple IP addresses: a cluster of LMAs or a blade
      architecture LMA may appear to the routing system as multiple LMAs
      with separate unicast IP addresses.  A MAG can initially select
      any of those LMA IP addresses as the LMA Address using e.g., DNS-
      and AAA-based solutions.  However, MAG's initial selection may be
      suboptimal from the LMA point of view and immediate redirection to
      a "proper LMA" would be needed.  The LMA could use [RFC5142] based
      approach but that would imply unnecessary setting up of a mobility
      session in a "wrong LMA" with associated backend support system
      interactions, involve additional signaling between the MAG and the
      LMA, and re-establishing mobility session to the new LMA again
      with associated signaling.
     
      [Qin]: As described in [RFC5142], it seems changing the home agent
      of mobile node is mainly becos load balance consideration or overloaded
      factor. Therefore not sure whether the bullet one(LMAs with multiple IP
      address) overlaps with bulltet two(Bypassing a load balancer).
      [Qin] In the section 5.4, it mentioned that Mobility Session can be Created
      After the Redirection. Not sure whether additional signaling between the MAG
      and the redirected LMA is required?
 
   o  Independence from DNS: DNS-based load balancing is a common
      practise.  However, keeping MAGs up-to-date with LMA load status
      using DNS is hard e.g., due caching and unpredictable zone update
      delays. Generally, LMAs constantly updating [RFC2136] zone's
      master DNS server might not feasible in a large PMIPv6 domain due
      to increased load on the master DNS server and additional
      background signaling.  Furthermore, MAGs may do (LMA) destination
      address selection decisions that are not in-line what the DNS
      administrator actually wanted [RFC3484].
 
      [Qin]: Are you saying DNS-based LMA discovery is independent from
      runtime LMA assignment described in this document? In some cases, DNS-based
      LMA discovery may cost too much. Then we can choose runtime LMA assignment instead of
      DNS-based approach.
      If in this way, I am not really clear what the DNS-based load balancing is here?
      Are you saying we need tradeoff between DNS based approach and runtime LMA assignment?
 
   o  Independence from AAA: AAA-based solutions have basically the same
      arguments as DNS-based solutions above.  It is also typical that
      AAA-based solutions offload the initial LMA selection to the DNS
      infrastructure.  The AAA infrastructure does not return an IP
      address or a Fully Qualified domain Name (FQDN) to a single LMA,
      rather a FQDN representing a group of LMAs.
 
      [Qin] It is better to have references to AAA based solution and DNS based solution.
 
   o  Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6
      specification does not specify how the PMIPv6 protocol should
      treat anycast addresses assigned to mobility agents.  Although
      [RFC4291] now allows using anycast addresses as source addresses,
      it does not make much sense using anycast addresses for the MAG to
      the LMA communication after the initial PBU/PBA exchange.  For
      example, a blade architecture LMA may appear to the routing system
      as multiple LMAs with separate unicast IP addresses and with one
      or more "grouping" anycast addresses.  
 
      [Qin]: Not sure [RFC4291] allow using anycast address as source adresses or destination adress?
      [Qin]: I don't really understand what this paragraph want to deliver?
             The mechanism for Runtime LMA assignment does not support IPv6 anycast addressing?
             It seems this parpagraph is not the reason for using runtime assignment? am I right?
 
In section 3:
   The LMA MUST NOT include the Redirect mobility option in the PBA and
   perform the redirection, unless the MAG indicated the redirection
   functionality support in the corresponding PBU using the Redirection-
   Capability mobility option.  The LMA MUST NOT include the Redirect
   mobility option unsolicited even if the MAG had earlier indicated
   support for the redirection functionality.
 
   [Qin] It seems to me that this assumption is too strict. What if MAG and LMA have a prioor aggreement that
   MAG support Rediction functionality?
 
 
In section 4.2:
 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Option Type   | Option Length |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      IPv6 r2LMA Address                       |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Optional IPv4 r2LMA Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

                         Redirect Mobility Option
 
   o  Option Type: 8-bit identifier set to TBD2.
 
   o  Option Length: 8-bit unsigned integer, representing the length of
      the Redirect mobility option in octets, excluding the Option Type
      and Length fields.  If the IPv4 LMA Address is included in the
      option, the Option Length MUST be set to 22.  Otherwise, the
      Option Length MUST be set to 18.
 
   o  Reserved: This field is reserved for future use.  MUST be set to
      zero.
 
   o  IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA.
 
   o  Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA.  This
      value is present if the r2LMA IPv4 address is available.
 
    [Qin]: I think whether IPv4 r2LMA address is included depends on
    a) the r2LMA IPv4 address is available by rfLMA b) 'F'flag is set
    to 1 in the Redirect-Capability Mobility Option? what am I missing?
 
In section 6:
   A MN can be multi-homed.  A single LMA entity should have the control
   over all possible multi-homed mobility sessions the MN has.  All
   mobility sessions a multi-homed MN may have SHOULD be anchored in the
   single LMA entity.  Therefore, once the MN has established one
   mobility session with one LMA, the subsequent mobility sessions of
   the same MN SHOULD be anchored to the LMA that was initially
   assigned.
   [Qin]: Little confused here. If MN has changed from
   rfLMA to r2LMA, there are two choices ensuing :
   a) all the mobility sessions should be moved from rfLMA to r2LMA.
   b) all the mobility sessions will still stay at rfLMA?
   which one is correct?
 
   One possible solution already supported by this specification is
   applying the redirection only for the very first initial attach a
   multi-homed MN does towards a PMIPv6 domain.  After the initial
   attach, the assigned r2LMA Address has been stored in the policy
   profile.  For the subsequent mobility sessions of the multi-homed MN,
   the same assigned r2LMA Address would be used and there is no need to
   contact the rfLMA.

   [Qin]: What if r2LMA is overloaded again and need to rediret the mobility session
   to another new r2LMA?
 
In Section 8:
   If a PMIPv6 domain deployment with a redirection requires that a
   rfLMA has to modify a received PBU in any way e.g., by changing the
   destination IP address field of the outer IP header, then the
   security mechanism (such as possible authentication options) used to
   protect the PBU must not cover the outer IP header on those parts
   that might get modified.  Alternatively, the rfLMA can do all
   required security mechanism processing on the received PBU and remove
   those security related options from the PBU that would cause the
   security check to fail on the r2LMA.

   [Qin]: It seems to me changing the security part in the PBU is a big challenging to runtime assignment.
   So I think maybe it is simpler to add another outer IP header which may sacrifice some processing overheads at rfLMA.
--Boundary_(ID_an4dooirHfeIj3v2SBmyzg)-- From jouni.nospam@gmail.com Fri Apr 16 09:02:18 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3E328C0CF for ; Fri, 16 Apr 2010 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=-1.374, BAYES_50=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBxlgka8rF0N for ; Fri, 16 Apr 2010 09:02:16 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 6A21928C178 for ; Fri, 16 Apr 2010 09:02:01 -0700 (PDT) Received: by bwz25 with SMTP id 25so3301970bwz.28 for ; Fri, 16 Apr 2010 09:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=qctTo2cEHkO6OovPh0Ee61OqeQ0SWjAFEkIRBBNtf04=; b=emjlSq5Z1UFMCsd6O6okLpkjudz12bvK4RL+LFu0dlDiYC9vjceSSlMqsnnPGsqYIa C87gHalYb2dSjOVL6L3puvnaoNRZyv6EK2Zklr13xOziAZrBXTi4o38/QiMXsZD0JB+k rMoOezF5IPOaAFNp8Lozak63KLYMfxT+OAkes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=C5AP1CoaGnKvUO9nLE4Mu2rr7I/kRVPeQJd45IiY1VJK+aUwLphElrzDThixSptAQ2 6elMS4ZGNQ0ZZoBfMg48RaDombE+DVV6TGqE3GAlqYTqJj+dKr3Sh3/GZq202znSSaJP fzmqBYq7+INy/6c+WAgFLINQxwBtjzww/GDKs= Received: by 10.204.132.196 with SMTP id c4mr1974408bkt.5.1271433708748; Fri, 16 Apr 2010 09:01:48 -0700 (PDT) Received: from a88-112-206-194.elisa-laajakaista.fi (a88-112-206-194.elisa-laajakaista.fi [88.112.206.194]) by mx.google.com with ESMTPS id 13sm1941668bwz.11.2010.04.16.09.01.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Apr 2010 09:01:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen X-Priority: 3 In-Reply-To: <002801cadc46$369ef910$23548a0a@china.huawei.com> Date: Fri, 16 Apr 2010 19:01:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <70F558D1-3955-4B70-9EB0-AC68A92D862D@gmail.com> References: <002801cadc46$369ef910$23548a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 16:02:18 -0000 Hi Qin, Thanks for the review! See my initial responses inline: On Apr 15, 2010, at 5:49 AM, Qin Wu wrote: > Hi, > In Anaheim I volunteered to review this I-D. I think this I-D has been = in good shape. Here is my review of redirection document. > = --------------------------------------------------------------------------= ------------------------------------------------------- > In the section 1: > o LMAs with multiple IP addresses: a cluster of LMAs or a blade > architecture LMA may appear to the routing system as multiple = LMAs > with separate unicast IP addresses. A MAG can initially select > any of those LMA IP addresses as the LMA Address using e.g., = DNS- > and AAA-based solutions. However, MAG's initial selection may = be > suboptimal from the LMA point of view and immediate redirection = to > a "proper LMA" would be needed. The LMA could use [RFC5142] = based > approach but that would imply unnecessary setting up of a = mobility > session in a "wrong LMA" with associated backend support system > interactions, involve additional signaling between the MAG and = the > LMA, and re-establishing mobility session to the new LMA again > with associated signaling. > =20 > [Qin]: As described in [RFC5142], it seems changing the home = agent=20 > of mobile node is mainly becos load balance consideration or = overloaded > factor. Therefore not sure whether the bullet one(LMAs with = multiple IP > address) overlaps with bulltet two(Bypassing a load balancer). These are two different cases. Bullet one is about a wrong LMA selection = decision made by a MAG that needs to be "corrected" by a LMA.. using = excess signaling and unnecessary intermediate, yet complete, state = creation in a LMA. Bullet two is about how to avoid a load balancing = entity becoming a bottleneck. > [Qin] In the section 5.4, it mentioned that Mobility Session can = be Created=20 > After the Redirection. Not sure whether additional signaling = between the MAG > and the redirected LMA is required? If you are referring to RFC5142 here, then before you can do the HA = switch you need to setup a mobility session in both MAG and LMA before = you can actually send HA switch messages followed by closing the old = mobility session & creating a new one. Also, in real systems setting up = a mobility session in a LMA would involve a huge amount of additional = signaling toward subscriber management systems and such. These are = "additional signaling" what we want to avoid. > =20 > o Independence from DNS: DNS-based load balancing is a common > practise. However, keeping MAGs up-to-date with LMA load status > using DNS is hard e.g., due caching and unpredictable zone = update > delays. Generally, LMAs constantly updating [RFC2136] zone's > master DNS server might not feasible in a large PMIPv6 domain = due > to increased load on the master DNS server and additional > background signaling. Furthermore, MAGs may do (LMA) = destination > address selection decisions that are not in-line what the DNS > administrator actually wanted [RFC3484]. > =20 > [Qin]: Are you saying DNS-based LMA discovery is independent = from > runtime LMA assignment described in this document? In some = cases, DNS-based > LMA discovery may cost too much. Then we can choose runtime LMA = assignment instead of > DNS-based approach.=20 Hmm.. not entirely sure what you are after here. However, typical = DNS-based load balancing solutions just use a round-robin feature when = returning multiple A records, thus spreading load among a number of = LMAs. The solution described in the draft does not need DNS for its load = balancing/redirection decision. Even if DNS pointed MAG to a certain = rfLMA, the rfLMA can still does a redirection decision independent what = DNS does.. > If in this way, I am not really clear what the DNS-based load = balancing is here? > Are you saying we need tradeoff between DNS based approach and = runtime LMA assignment? See above. Also, we need a solution that does not depend on DNS at all. > =20 > o Independence from AAA: AAA-based solutions have basically the = same > arguments as DNS-based solutions above. It is also typical that > AAA-based solutions offload the initial LMA selection to the DNS > infrastructure. The AAA infrastructure does not return an IP > address or a Fully Qualified domain Name (FQDN) to a single LMA, > rather a FQDN representing a group of LMAs. > =20 > [Qin] It is better to have references to AAA based solution and = DNS based solution. Ok. What about: AAA solution -> RFC5779 ? DNS solution -> maybe ietf-draft-netlmm-lma-discovery ?? > =20 > o Support for IPv6 anycast addressing [RFC4291]: the current = PMIPv6 > specification does not specify how the PMIPv6 protocol should > treat anycast addresses assigned to mobility agents. Although > [RFC4291] now allows using anycast addresses as source = addresses, > it does not make much sense using anycast addresses for the MAG = to > the LMA communication after the initial PBU/PBA exchange. For > example, a blade architecture LMA may appear to the routing = system > as multiple LMAs with separate unicast IP addresses and with one > or more "grouping" anycast addresses. =20 > =20 > [Qin]: Not sure [RFC4291] allow using anycast address as source = adresses or destination adress? RFC4291 Appendix B first bullet says that anycast address restrictions = of RFC3515 were removed. In RFC3515 Section 2.6 use of anycast addresses = as a source address or as an address of an IPv6 host were explicitly = prohibited. > [Qin]: I don't really understand what this paragraph want to = deliver? > The mechanism for Runtime LMA assignment does not support = IPv6 anycast addressing? > It seems this parpagraph is not the reason for using = runtime assignment? am I right? Nop. A pool of (rf)LMAs may have anycast address. Once you contact such = LMA, you better be redirected to a unicast address of a LMA.. otherwise = stuff breaks. > =20 > In section 3: > The LMA MUST NOT include the Redirect mobility option in the PBA = and > perform the redirection, unless the MAG indicated the redirection > functionality support in the corresponding PBU using the = Redirection- > Capability mobility option. The LMA MUST NOT include the Redirect > mobility option unsolicited even if the MAG had earlier indicated > support for the redirection functionality. > =20 > [Qin] It seems to me that this assumption is too strict. What if = MAG and LMA have a prioor aggreement that > MAG support Rediction functionality? That is a normal way we indicate support for certain new features in = protocols. That allows mixing MAGs and LMAs e.g. with different software = releases in a PMIPv6 Domain. > =20 > =20 > In section 4.2: > =20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type | Option Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | IPv6 r2LMA Address | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional IPv4 r2LMA Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 >=20 > Redirect Mobility Option > =20 > o Option Type: 8-bit identifier set to TBD2. > =20 > o Option Length: 8-bit unsigned integer, representing the length = of > the Redirect mobility option in octets, excluding the Option = Type > and Length fields. If the IPv4 LMA Address is included in the > option, the Option Length MUST be set to 22. Otherwise, the > Option Length MUST be set to 18. > =20 > o Reserved: This field is reserved for future use. MUST be set to > zero. > =20 > o IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. > =20 > o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. = This > value is present if the r2LMA IPv4 address is available. > =20 > [Qin]: I think whether IPv4 r2LMA address is included depends on=20= > a) the r2LMA IPv4 address is available by rfLMA b) 'F'flag is set > to 1 in the Redirect-Capability Mobility Option? what am I = missing? You are right about the 'F' flag missing in the selection rule = description, thanks. Actually, this whole option has to be modified = slightly. The ipv4-support-18 now defines that in case of IPv4 transport = we do not carry IPv6 proxy-CoA and LMAA anywhere anymore. Effectively = this means the IPv6 r2LMA address should also be optional in Redirect = Mobility Option. The new Redirect Mobility option will have IPv6 LMAA or = IPv4 LMAA or both. > =20 > In section 6: > A MN can be multi-homed. A single LMA entity should have the = control > over all possible multi-homed mobility sessions the MN has. All > mobility sessions a multi-homed MN may have SHOULD be anchored in = the > single LMA entity. Therefore, once the MN has established one > mobility session with one LMA, the subsequent mobility sessions of > the same MN SHOULD be anchored to the LMA that was initially > assigned. > [Qin]: Little confused here. If MN has changed from=20 > rfLMA to r2LMA, there are two choices ensuing : > a) all the mobility sessions should be moved from rfLMA to r2LMA. > b) all the mobility sessions will still stay at rfLMA? > which one is correct? c) all subsequent mobility sessions established for the same multi-homed = MN (independent which access/MAG/interface is used) should to be created = on the r2LMA that was initially assigned to the MN. > =20 > One possible solution already supported by this specification is > applying the redirection only for the very first initial attach a > multi-homed MN does towards a PMIPv6 domain. After the initial > attach, the assigned r2LMA Address has been stored in the policy > profile. For the subsequent mobility sessions of the multi-homed = MN, > the same assigned r2LMA Address would be used and there is no need = to > contact the rfLMA. >=20 > [Qin]: What if r2LMA is overloaded again and need to rediret the = mobility session > to another new r2LMA? We do not support mid-session redirection by the request by the WG. That = means new mobility sessions for the same multi-homed MN will be anchored = to the existing r2LMA. If that fails due overload, then the new mobility = session gets rejected. > =20 > In Section 8: > If a PMIPv6 domain deployment with a redirection requires that a > rfLMA has to modify a received PBU in any way e.g., by changing the > destination IP address field of the outer IP header, then the > security mechanism (such as possible authentication options) used = to > protect the PBU must not cover the outer IP header on those parts > that might get modified. Alternatively, the rfLMA can do all > required security mechanism processing on the received PBU and = remove > those security related options from the PBU that would cause the > security check to fail on the r2LMA. >=20 > [Qin]: It seems to me changing the security part in the PBU is a = big challenging to runtime assignment. > So I think maybe it is simpler to add another outer IP header which = may sacrifice some processing overheads at rfLMA. I don't think so. When the rfLMA PMIPv6 "process" received the PBU, = IPsec or other security processing has already been done and the PMIPv6 = "process" sees the plain PBU. After that modifying PBU outer IP header = is no issue. Within a Redirection Domain there is no issue of rfLMA to = forward plain PBU to r2LMA. Alternatively, the rfLMA can re-protect the = PBU using the SA between rfLMA and r2LMA. This is bound to work, *if* = the PBU/PBA do not contain some authenticating mobility option covering = also outer transport IP headers. Whatever happens here is transparent to = MAG or r2LMA. - Jouni > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Mon Apr 19 12:30:15 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B643A6A21 for ; Mon, 19 Apr 2010 12:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmiZQR85IQDa for ; Mon, 19 Apr 2010 12:30:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DAA163A683A for ; Mon, 19 Apr 2010 12:30:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYHAFJMzEutJV2c/2dsb2JhbACBP45DiyZTAnGkCJkthQ4EgzKIUg X-IronPort-AV: E=Sophos;i="4.52,237,1270425600"; d="scan'208,217";a="103033495" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 19 Apr 2010 19:30:01 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o3JJU1In022968 for ; Mon, 19 Apr 2010 19:30:01 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Apr 2010 15:27:36 -0400 Received: from 171.70.249.76 ([171.70.249.76]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Apr 2010 19:27:36 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 19 Apr 2010 12:31:46 -0700 From: Rajeev Koodli To: Message-ID: Thread-Topic: Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2A== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3354525106_36909571" X-OriginalArrivalTime: 19 Apr 2010 19:27:36.0282 (UTC) FILETIME=[5DD74BA0:01CADFF6] Subject: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 19:30:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3354525106_36909571 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable FYI..Jari and the chairs are planning to send the following LS to 3GPP informing them of NetExt=B9s work on Flow Mobility. Please provide comments, if any.. Thanks, -Rajeev .................................... =20 April 14, 2010 =20 To: 3GPP SA2 Chairman: Balazs Bertenyi Vice chairman: Andy Bennett Vice chairman: Hong Liu =20 Subject: Flow mobility feature being specified for Proxy Mobile IPv6 (RFC5213) in the NetExt WG =20 Dear Balazs, Andy and, Hong, We would like to inform you about the work being done on extending Proxy Mobile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the IETF. The NetExt WG charter was revised and approved in February 2010 with the following new goal and milestone: 1. Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flo= w Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces =AD Oct 2010 Please consider this as an informative update for SA2 on the developments i= n NetExt WG in the IETF. Best Regards, IETF NetExt WG chairs IETF Internet area director Rajeev Koodli Jari Arkko Basavaraj Patil --B_3354525106_36909571 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Liaison Statement on Flow Mobility to 3GPP
FYI..Jari and the chairs are planning to send the following LS to 3GPP info= rming them of NetExt’s work on Flow Mobility.
Please provide comments, if any..

Thanks,

-Rajeev
....................................
 

Apr= il 14, 2010
 
To: 3GPP SA2
            &nb= sp;     Chairman: Balazs Bertenyi
            &nb= sp;     Vice chairman: Andy Bennett
            &nb= sp;     Vice chairman: Hong Liu
 
Subject:  Flow mobility feature being specified for Proxy Mobile IP= v6 (RFC5213) in the NetExt WG
Dear Balazs, Andy and, Hong,

We would like to inform you about the work being done on extending Proxy Mo= bile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the IET= F. The NetExt WG charter was revised and approved in February 2010 with the = following new goal and milestone:

1.    Initial WG document(s) on Proxy Mobile IPv6 Extensions= to Support Flow Mobility and Inter-access Handovers on a Logical Interface = over Multiple Physical Interfaces – Oct 2010  

Please consider this as an informative update for SA2 on the developments i= n NetExt WG in the IETF.

Best Regards,

IETF NetExt WG chairs          = ;            IET= F Internet area director
Rajeev Koodli           &= nbsp;            = ;            &nb= sp;Jari Arkko
Basavaraj Patil
 --B_3354525106_36909571-- From yokota@kddilabs.jp Mon Apr 19 18:05:43 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12ED23A67B4 for ; Mon, 19 Apr 2010 18:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=2.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDqtl0-wIQ8B for ; Mon, 19 Apr 2010 18:05:41 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 9F8193A63C9 for ; Mon, 19 Apr 2010 18:05:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 50835EC8E0 for ; Tue, 20 Apr 2010 10:05:29 +0900 (JST) Received: from ultra.mip.kddilabs.jp (unknown [2001:200:601:402:203:baff:fe2c:bc3]) by mandala.kddilabs.jp (Postfix) with ESMTP id 39D8EEC8C5 for ; Tue, 20 Apr 2010 10:05:14 +0900 (JST) Received: from [127.0.0.1] (unknown [172.19.90.31]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 104461BFFB for ; Tue, 20 Apr 2010 10:03:35 +0900 (JST) Message-ID: <4BCCFD87.3000704@kddilabs.jp> Date: Tue, 20 Apr 2010 10:04:07 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 01:05:43 -0000 Hi Rajeev, I think this is a great step for this work. I don't have any comment on=20 the LS, but have one naive question. What can 3GPP folks expect from=20 this prospective WG document (e.g., some part of TR23.861) because we=20 haven't well explored and discussed the solution space, yet? Regards, --=20 Hidetoshi (2010/04/20 4:31), Rajeev Koodli wrote: > > FYI..Jari and the chairs are planning to send the following LS to 3GPP > informing them of NetExt=E2=80=99s work on Flow Mobility. > Please provide comments, if any.. > > Thanks, > > -Rajeev > .................................... > > > April 14, 2010 > > To: 3GPP SA2 > Chairman: Balazs Bertenyi > Vice chairman: Andy Bennett > Vice chairman: Hong Liu > > *Subject: Flow mobility feature being specified for Proxy Mobile IPv6 > (RFC5213) in the NetExt WG > * > Dear Balazs, Andy and, Hong, > > We would like to inform you about the work being done on extending Prox= y > Mobile IPv6 (RFC5213) to support flow mobility within the NetExt WG in > the IETF. The NetExt WG charter was revised and approved in February > 2010 with the following new goal and milestone: > > 1. Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support > Flow Mobility and Inter-access Handovers on a Logical Interface over > Multiple Physical Interfaces =E2=80=93 Oct 2010 > > Please consider this as an informative update for SA2 on the > developments in NetExt WG in the IETF. > > Best Regards, > > IETF NetExt WG chairs IETF Internet area director > Rajeev Koodli Jari Arkko > Basavaraj Patil > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Mon Apr 19 18:51:49 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C1E3A6956 for ; Mon, 19 Apr 2010 18:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.313 X-Spam-Level: X-Spam-Status: No, score=-7.313 tagged_above=-999 required=5 tests=[AWL=1.219, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vswwo0SUAQwK for ; Mon, 19 Apr 2010 18:51:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8A3763A6846 for ; Mon, 19 Apr 2010 18:51:48 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAGOlzEutJV2a/2dsb2JhbACbfAJxozSZVIUOBIMyiFM X-IronPort-AV: E=Sophos;i="4.52,239,1270425600"; d="scan'208";a="103116519" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2010 01:51:39 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o3K1pc3c030252; Tue, 20 Apr 2010 01:51:38 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Apr 2010 21:49:13 -0400 Received: from 171.70.249.76 ([171.70.249.76]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Apr 2010 01:49:12 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 19 Apr 2010 18:53:23 -0700 From: Rajeev Koodli To: Hidetoshi Yokota , Message-ID: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrgLEJcoYaCuLWYKkyR8wm57hxVGw== In-Reply-To: <4BCCFD87.3000704@kddilabs.jp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Apr 2010 01:49:13.0201 (UTC) FILETIME=[AD77DE10:01CAE02B] Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 01:51:49 -0000 Hello Yokota-san, I think 3GPP folks would know that a protocol specification from IETF would be available for their own work (TR or future TS). Regards, -Rajeev On 4/19/10 6:04 PM, "Hidetoshi Yokota" wrote: > Hi Rajeev, I think this is a great step for this work. I don't have any > comment on the LS, but have one naive question. What can 3GPP folks expect > from this prospective WG document (e.g., some part of TR23.861) because we > haven't well explored and discussed the solution space, yet? Regards, -- > Hidetoshi (2010/04/20 4:31), > Rajeev Koodli wrote: > > FYI..Jari and the > chairs are planning to send the following LS to 3GPP > informing them of > NetExt=B9s work on Flow Mobility. > Please provide comments, if any.. > > > Thanks, > > -Rajeev > .................................... > > > April 14, > 2010 > > To: 3GPP SA2 > Chairman: Balazs Bertenyi > Vice chairman: Andy > Bennett > Vice chairman: Hong Liu > > *Subject: Flow mobility feature being > specified for Proxy Mobile IPv6 > (RFC5213) in the NetExt WG > * > Dear > Balazs, Andy and, Hong, > > We would like to inform you about the work being > done on extending Proxy > Mobile IPv6 (RFC5213) to support flow mobility > within the NetExt WG in > the IETF. The NetExt WG charter was revised and > approved in February > 2010 with the following new goal and milestone: > > 1. > Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support > Flow > Mobility and Inter-access Handovers on a Logical Interface over > Multiple > Physical Interfaces =AD Oct 2010 > > Please consider this as an informative > update for SA2 on the > developments in NetExt WG in the IETF. > > Best > Regards, > > IETF NetExt WG chairs IETF Internet area director > Rajeev Koodli > Jari Arkko > Basavaraj Patil > > > > > _______________________________________________ > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext ________________________________ > _______________ netext mailing > list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Mon Apr 19 19:25:30 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C0B3A67B7 for ; Mon, 19 Apr 2010 19:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.566 X-Spam-Level: ** X-Spam-Status: No, score=2.566 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83FOAZ3zP83f for ; Mon, 19 Apr 2010 19:25:21 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CFE863A6846 for ; Mon, 19 Apr 2010 19:25:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1500CY8LDP8E@szxga04-in.huawei.com> for netext@ietf.org; Tue, 20 Apr 2010 10:25:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L15004QRLDPV5@szxga04-in.huawei.com> for netext@ietf.org; Tue, 20 Apr 2010 10:25:01 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1500EKULDO7W@szxml06-in.huawei.com> for netext@ietf.org; Tue, 20 Apr 2010 10:25:01 +0800 (CST) Date: Tue, 20 Apr 2010 10:25:01 +0800 From: Qin Wu To: jouni korhonen Message-id: <01d301cae030$ae6b2570$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002801cadc46$369ef910$23548a0a@china.huawei.com> <70F558D1-3955-4B70-9EB0-AC68A92D862D@gmail.com> Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 02:25:30 -0000 Hi,Jouni: ----- Original Message ----- From: "jouni korhonen" To: "Qin Wu" Cc: Sent: Saturday, April 17, 2010 12:01 AM Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 Hi Qin, Thanks for the review! See my initial responses inline: On Apr 15, 2010, at 5:49 AM, Qin Wu wrote: > Hi, > In Anaheim I volunteered to review this I-D. I think this I-D has been in good shape. Here is my review of redirection document. > --------------------------------------------------------------------------------------------------------------------------------- > In the section 1: > o LMAs with multiple IP addresses: a cluster of LMAs or a blade > architecture LMA may appear to the routing system as multiple LMAs > with separate unicast IP addresses. A MAG can initially select > any of those LMA IP addresses as the LMA Address using e.g., DNS- > and AAA-based solutions. However, MAG's initial selection may be > suboptimal from the LMA point of view and immediate redirection to > a "proper LMA" would be needed. The LMA could use [RFC5142] based > approach but that would imply unnecessary setting up of a mobility > session in a "wrong LMA" with associated backend support system > interactions, involve additional signaling between the MAG and the > LMA, and re-establishing mobility session to the new LMA again > with associated signaling. > > [Qin]: As described in [RFC5142], it seems changing the home agent > of mobile node is mainly becos load balance consideration or overloaded > factor. Therefore not sure whether the bullet one(LMAs with multiple IP > address) overlaps with bulltet two(Bypassing a load balancer). These are two different cases. Bullet one is about a wrong LMA selection decision made by a MAG that needs to be "corrected" by a LMA.. using excess signaling and unnecessary intermediate, yet complete, state creation in a LMA. Bullet two is about how to avoid a load balancing entity becoming a bottleneck. [Qin]: Okay, Would you like to clarify in which scenario will the wrong LMA selection happen? a) In the exception case In this case, why will MAG choose the wrong LMA? b) load balance case In this case, the candiate LMA to which the MAG is going to register intend to offload to the other backup LMAs. Do you think this candidate LMA can be looked as wrong LMA? c) or overloaded situation In this case, the candiate LMA to which the MAG is going to register is overloaded and need to transfer the load out.Do you think this candidate LMA can be looked as wrong LMA? > [Qin] In the section 5.4, it mentioned that Mobility Session can be Created > After the Redirection. Not sure whether additional signaling between the MAG > and the redirected LMA is required? If you are referring to RFC5142 here, then before you can do the HA switch you need to setup a mobility session in both MAG and LMA before you can actually send HA switch messages followed by closing the old mobility session & creating a new one. Also, in real systems setting up a mobility session in a LMA would involve a huge amount of additional signaling toward subscriber management systems and such. These are "additional signaling" what we want to avoid. [Qin]: Thank for your clarification. That is to say, In contrast with HA switch described in RFC5142, the Redirection mechanims descibeds in the section 5.4 does not need additional signaling to setup mobility session at the rfLMA. > > o Independence from DNS: DNS-based load balancing is a common > practise. However, keeping MAGs up-to-date with LMA load status > using DNS is hard e.g., due caching and unpredictable zone update > delays. Generally, LMAs constantly updating [RFC2136] zone's > master DNS server might not feasible in a large PMIPv6 domain due > to increased load on the master DNS server and additional > background signaling. Furthermore, MAGs may do (LMA) destination > address selection decisions that are not in-line what the DNS > administrator actually wanted [RFC3484]. > > [Qin]: Are you saying DNS-based LMA discovery is independent from > runtime LMA assignment described in this document? In some cases, DNS-based > LMA discovery may cost too much. Then we can choose runtime LMA assignment instead of > DNS-based approach. Hmm.. not entirely sure what you are after here. However, typical DNS-based load balancing solutions just use a round-robin feature when returning multiple A records, thus spreading load among a number of LMAs. The solution described in the draft does not need DNS for its load balancing/redirection decision. Even if DNS pointed MAG to a certain rfLMA, the rfLMA can still does a redirection decision independent what DNS does.. [Qin]: I agree. That is to say, Redirection based load balancing is more effective and efficient than DNS-based load balancing. > If in this way, I am not really clear what the DNS-based load balancing is here? > Are you saying we need tradeoff between DNS based approach and runtime LMA assignment? See above. Also, we need a solution that does not depend on DNS at all. [Qin]: Okay, that is what you said in the draft. > > o Independence from AAA: AAA-based solutions have basically the same > arguments as DNS-based solutions above. It is also typical that > AAA-based solutions offload the initial LMA selection to the DNS > infrastructure. The AAA infrastructure does not return an IP > address or a Fully Qualified domain Name (FQDN) to a single LMA, > rather a FQDN representing a group of LMAs. > > [Qin] It is better to have references to AAA based solution and DNS based solution. Ok. What about: AAA solution -> RFC5779 ? DNS solution -> maybe ietf-draft-netlmm-lma-discovery ?? [Qin]: Sounds good to me. > > o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 > specification does not specify how the PMIPv6 protocol should > treat anycast addresses assigned to mobility agents. Although > [RFC4291] now allows using anycast addresses as source addresses, > it does not make much sense using anycast addresses for the MAG to > the LMA communication after the initial PBU/PBA exchange. For > example, a blade architecture LMA may appear to the routing system > as multiple LMAs with separate unicast IP addresses and with one > or more "grouping" anycast addresses. > > [Qin]: Not sure [RFC4291] allow using anycast address as source adresses or destination adress? RFC4291 Appendix B first bullet says that anycast address restrictions of RFC3515 were removed. In RFC3515 Section 2.6 use of anycast addresses as a source address or as an address of an IPv6 host were explicitly prohibited. [Qin]: Thank for your clarification by providing references. I agree it doesn't make sense when MAG use anycast address as source address. However I am wondering whether it makes sense to use ancast address for the LMA, in other words, when the MAG forwards the data to the LMA, is it possible for MAG to generate one data packet with anycast address of LMA as destination address? > [Qin]: I don't really understand what this paragraph want to deliver? > The mechanism for Runtime LMA assignment does not support IPv6 anycast addressing? > It seems this parpagraph is not the reason for using runtime assignment? am I right? Nop. A pool of (rf)LMAs may have anycast address. Once you contact such LMA, you better be redirected to a unicast address of a LMA.. otherwise stuff breaks. [Qin]: I agree. But it seems a little confusing to use "Support for IPv6 anycast addressing" as title of this bullet. People will thought MAG or LMA can support IPv6 anycast addressing when communciation between MAG and LMA? am I right? > > In section 3: > The LMA MUST NOT include the Redirect mobility option in the PBA and > perform the redirection, unless the MAG indicated the redirection > functionality support in the corresponding PBU using the Redirection- > Capability mobility option. The LMA MUST NOT include the Redirect > mobility option unsolicited even if the MAG had earlier indicated > support for the redirection functionality. > > [Qin] It seems to me that this assumption is too strict. What if MAG and LMA have a prioor aggreement that > MAG support Rediction functionality? That is a normal way we indicate support for certain new features in protocols. That allows mixing MAGs and LMAs e.g. with different software releases in a PMIPv6 Domain. [Qin]: Okay. > > > In section 4.2: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type | Option Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | IPv6 r2LMA Address | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional IPv4 r2LMA Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Redirect Mobility Option > > o Option Type: 8-bit identifier set to TBD2. > > o Option Length: 8-bit unsigned integer, representing the length of > the Redirect mobility option in octets, excluding the Option Type > and Length fields. If the IPv4 LMA Address is included in the > option, the Option Length MUST be set to 22. Otherwise, the > Option Length MUST be set to 18. > > o Reserved: This field is reserved for future use. MUST be set to > zero. > > o IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. > > o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This > value is present if the r2LMA IPv4 address is available. > > [Qin]: I think whether IPv4 r2LMA address is included depends on > a) the r2LMA IPv4 address is available by rfLMA b) 'F'flag is set > to 1 in the Redirect-Capability Mobility Option? what am I missing? You are right about the 'F' flag missing in the selection rule description, thanks. Actually, this whole option has to be modified slightly. The ipv4-support-18 now defines that in case of IPv4 transport we do not carry IPv6 proxy-CoA and LMAA anywhere anymore. Effectively this means the IPv6 r2LMA address should also be optional in Redirect Mobility Option. The new Redirect Mobility option will have IPv6 LMAA or IPv4 LMAA or both. [Qin]: Good. > > In section 6: > A MN can be multi-homed. A single LMA entity should have the control > over all possible multi-homed mobility sessions the MN has. All > mobility sessions a multi-homed MN may have SHOULD be anchored in the > single LMA entity. Therefore, once the MN has established one > mobility session with one LMA, the subsequent mobility sessions of > the same MN SHOULD be anchored to the LMA that was initially > assigned. > [Qin]: Little confused here. If MN has changed from > rfLMA to r2LMA, there are two choices ensuing : > a) all the mobility sessions should be moved from rfLMA to r2LMA. > b) all the mobility sessions will still stay at rfLMA? > which one is correct? c) all subsequent mobility sessions established for the same multi-homed MN (independent which access/MAG/interface is used) should to be created on the r2LMA that was initially assigned to the MN. [Qin]: Good, I think that is reasonable to me. > > One possible solution already supported by this specification is > applying the redirection only for the very first initial attach a > multi-homed MN does towards a PMIPv6 domain. After the initial > attach, the assigned r2LMA Address has been stored in the policy > profile. For the subsequent mobility sessions of the multi-homed MN, > the same assigned r2LMA Address would be used and there is no need to > contact the rfLMA. > > [Qin]: What if r2LMA is overloaded again and need to rediret the mobility session > to another new r2LMA? We do not support mid-session redirection by the request by the WG. That means new mobility sessions for the same multi-homed MN will be anchored to the existing r2LMA. If that fails due overload, then the new mobility session gets rejected. [Qin]: Okay. > > In Section 8: > If a PMIPv6 domain deployment with a redirection requires that a > rfLMA has to modify a received PBU in any way e.g., by changing the > destination IP address field of the outer IP header, then the > security mechanism (such as possible authentication options) used to > protect the PBU must not cover the outer IP header on those parts > that might get modified. Alternatively, the rfLMA can do all > required security mechanism processing on the received PBU and remove > those security related options from the PBU that would cause the > security check to fail on the r2LMA. > > [Qin]: It seems to me changing the security part in the PBU is a big challenging to runtime assignment. > So I think maybe it is simpler to add another outer IP header which may sacrifice some processing overheads at rfLMA. I don't think so. When the rfLMA PMIPv6 "process" received the PBU, IPsec or other security processing has already been done and the PMIPv6 "process" sees the plain PBU. After that modifying PBU outer IP header is no issue. Within a Redirection Domain there is no issue of rfLMA to forward plain PBU to r2LMA. Alternatively, the rfLMA can re-protect the PBU using the SA between rfLMA and r2LMA. This is bound to work, *if* the PBU/PBA do not contain some authenticating mobility option covering also outer transport IP headers. Whatever happens here is transparent to MAG or r2LMA. [Qin]; Okay, Does it mean only transport mode ESP can be used to protect PBU exchanged between MAG and rfLMA if IPSEC protection is employed and there are some authentication mobility option in such PBU. Becos in the AH or tunnel mode ESP, the outer IP header will be protected. am I right? As regarding to what security mechanism can be used between rfLMA and r2LMA, if we assume plain PBU is protected by transport mode ESP, then whatever security mechanism is used does not matter, Since it has been assumed that there are trust relationship between rfLMA and r2LMA. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From pierrick.seite@orange-ftgroup.com Tue Apr 20 00:59:37 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA81F3A679C for ; Tue, 20 Apr 2010 00:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HNsS1sbbNWB for ; Tue, 20 Apr 2010 00:59:37 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 05DF03A6A4F for ; Tue, 20 Apr 2010 00:59:35 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 796CF760033; Tue, 20 Apr 2010 09:55:23 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id CA768768010; Tue, 20 Apr 2010 09:51:28 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 09:50:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2010 09:50:19 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462CDD092@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrgLEJcoYaCuLWYKkyR8wm57hxVGwAMTaKQ References: <4BCCFD87.3000704@kddilabs.jp> From: To: , , X-OriginalArrivalTime: 20 Apr 2010 07:50:19.0607 (UTC) FILETIME=[1FA70E70:01CAE05E] Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 07:59:37 -0000 Hi, I agree, this LS is a very good initiative. I guess Netext should take = into account 3GPP requirements, if any. Right? Regards, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Rajeev Koodli > Envoy=E9=A0: mardi 20 avril 2010 03:53 > =C0=A0: Hidetoshi Yokota; netext@ietf.org > Objet=A0: Re: [netext] Liaison Statement on Flow Mobility to 3GPP >=20 >=20 > Hello Yokota-san, >=20 > I think 3GPP folks would know that a protocol specification from IETF > would > be available for their own work (TR or future TS). >=20 > Regards, >=20 > -Rajeev >=20 >=20 >=20 >=20 > On 4/19/10 6:04 PM, "Hidetoshi Yokota" wrote: >=20 > > Hi Rajeev, >=20 > I think this is a great step for this work. I don't have any > > comment on > the LS, but have one naive question. What can 3GPP folks expect > > from > this prospective WG document (e.g., some part of TR23.861) because we > > > haven't well explored and discussed the solution space, yet? >=20 > Regards, > -- > > > Hidetoshi >=20 > (2010/04/20 4:31), >=20 >=20 > > Rajeev Koodli wrote: > > > > FYI..Jari and the > > chairs are planning to send the following LS to 3GPP > > informing them of > > NetExt=B9s work on Flow Mobility. > > Please provide comments, if any.. > > > > > > Thanks, > > > > -Rajeev > > .................................... > > > > > > April 14, > > 2010 > > > > To: 3GPP SA2 > > Chairman: Balazs Bertenyi > > Vice chairman: Andy > > Bennett > > Vice chairman: Hong Liu > > > > *Subject: Flow mobility feature being > > specified for Proxy Mobile IPv6 > > (RFC5213) in the NetExt WG > > * > > Dear > > Balazs, Andy and, Hong, > > > > We would like to inform you about the work being > > done on extending Proxy > > Mobile IPv6 (RFC5213) to support flow mobility > > within the NetExt WG in > > the IETF. The NetExt WG charter was revised and > > approved in February > > 2010 with the following new goal and milestone: > > > > 1. > > Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support > > Flow > > Mobility and Inter-access Handovers on a Logical Interface over > > Multiple > > Physical Interfaces =AD Oct 2010 > > > > Please consider this as an informative > > update for SA2 on the > > developments in NetExt WG in the IETF. > > > > Best > > Regards, > > > > IETF NetExt WG chairs IETF Internet area director > > Rajeev Koodli > > Jari Arkko > > Basavaraj Patil > > > > > > > > > > _______________________________________________ > > netext mailing list > > > > netext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netext >=20 > ________________________________ > > _______________ > netext mailing > > list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Tue Apr 20 07:00:33 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CD13A68AE for ; Tue, 20 Apr 2010 07:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.736 X-Spam-Level: X-Spam-Status: No, score=-105.736 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOdLjImM-g-j for ; Tue, 20 Apr 2010 07:00:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3653128C18B for ; Tue, 20 Apr 2010 07:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1271772019; x=1303308019; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Rajeev=20Koodli=20,=20"netext@i etf.org"=20|Date:=20Tue,=2020=20Apr=2020 10=2007:00:03=20-0700|Subject:=20RE:=20[netext]=20Liaison =20Statement=20on=20Flow=20Mobility=20to=203GPP |Thread-Topic:=20[netext]=20Liaison=20Statement=20on=20Fl ow=20Mobility=20to=203GPP|Thread-Index:=20Acrf9vKv/KT/1NV EMkaH9jfbV9e/2AAmML6A|Message-ID:=20 |References:=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_BF345F63074F8040B58C00A186FCA57F1EFEF D6EA1NALASEXMB04na_"|MIME-Version:=201.0; bh=mwAaG+Rr2zkHRjv2lbzKt9/j3QwCEith4U5422c9h8o=; b=DnGUWyd1FFdKgUiLpd0eq81QqOSykR3USWc7a9bT1lGIG/K2Rc2dvsLs nKGpDM2YzPehIb9La3uyLPc2OjFvU4GVoGgwnwU0+MEjU1hBcsWB9OCpK 1BIGlUzSih6Xq21BupPZqN1Ee/tb3wJ/nVIHNfvR8g8HOnj31bUCGUpsO g=; X-IronPort-AV: E=McAfee;i="5400,1158,5957"; a="39256077" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine01.qualcomm.com with ESMTP; 20 Apr 2010 07:00:07 -0700 X-IronPort-AV: E=Sophos;i="4.52,241,1270450800"; d="scan'208,217";a="18712993" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Apr 2010 07:00:07 -0700 Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 20 Apr 2010 07:00:06 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.0.689.0; Tue, 20 Apr 2010 07:00:06 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 20 Apr 2010 07:00:06 -0700 From: "Laganier, Julien" To: Rajeev Koodli , "netext@ietf.org" Date: Tue, 20 Apr 2010 07:00:03 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF345F63074F8040B58C00A186FCA57F1EFEFD6EA1NALASEXMB04na_" MIME-Version: 1.0 Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 14:00:33 -0000 --_000_BF345F63074F8040B58C00A186FCA57F1EFEFD6EA1NALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rajeev, I am unfamiliar with an IETF WG spontaneously generating a Liaison Statemen= ts to another organization -- Given that a contribution S2-101433 (link bel= ow) from Cisco and Intel was discussed at the last physical 3GPP SA2 WG mee= ting in San Francisco and already outlined in a much detailed fashion that = the IETF NETEXT WG was rechartered to work on PMIPv6 flow mobility, I am wo= ndering what would be the intended outcome of sending such an LS. --julien From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Rajeev Koodli Sent: Monday, April 19, 2010 12:32 PM To: netext@ietf.org Subject: [netext] Liaison Statement on Flow Mobility to 3GPP FYI..Jari and the chairs are planning to send the following LS to 3GPP info= rming them of NetExt's work on Flow Mobility. Please provide comments, if any.. Thanks, -Rajeev .................................... April 14, 2010 To: 3GPP SA2 Chairman: Balazs Bertenyi Vice chairman: Andy Bennett Vice chairman: Hong Liu Subject: Flow mobility feature being specified for Proxy Mobile IPv6 (RFC5= 213) in the NetExt WG Dear Balazs, Andy and, Hong, We would like to inform you about the work being done on extending Proxy Mo= bile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the IE= TF. The NetExt WG charter was revised and approved in February 2010 with th= e following new goal and milestone: 1. Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flo= w Mobility and Inter-access Handovers on a Logical Interface over Multiple = Physical Interfaces - Oct 2010 Please consider this as an informative update for SA2 on the developments i= n NetExt WG in the IETF. Best Regards, IETF NetExt WG chairs IETF Internet area director Rajeev Koodli Jari Arkko Basavaraj Patil --_000_BF345F63074F8040B58C00A186FCA57F1EFEFD6EA1NALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Liaison Statement on Flow Mobility to 3GPP

Hello Rajeev,

I am unfamiliar with an IETF WG spontaneously generating a Liaison Statements to another organization -- Given that a contribution S2-101433 (link below) fr= om Cisco and Intel was discussed at the last physical 3GPP SA2 WG meeting in S= an Francisco and already outlined in a much detailed fashion that the IETF NET= EXT WG was rechartered to work on PMIPv6 flow mobility, I am wondering what wou= ld be the intended outcome of sending such an LS.

<ftp://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_78_San_Francisco/Docs/S= 2-101433.zip>

--julien

 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Monday, April 19, 2010 12:32 PM
To: netext@ietf.org
Subject: [netext] Liaison Statement on Flow Mobility to 3GPP

 


FYI..Jari and the chairs are planning to send the following LS to 3GPP informing them of NetExt’s work on Flow Mobility.
Please provide comments, if any..

Thanks,

-Rajeev
....................................
 

April 14, 2010
 
To: 3GPP SA2
            &nb= sp;     Chairman: Balazs Bertenyi
            &nb= sp;     Vice chairman: Andy Bennett
            &nb= sp;     Vice chairman: Hong Liu
 
Subject:  Flow mobility feature being specified for Proxy Mobile IP= v6 (RFC5213) in the NetExt WG

Dear Balazs, Andy and, Hong,

We would like to inform you about the work being done on extending Proxy Mo= bile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the IETF. T= he NetExt WG charter was revised and approved in February 2010 with the follow= ing new goal and milestone:

1.    Initial WG document(s) on Proxy Mobile IPv6 Extensions= to Support Flow Mobility and Inter-access Handovers on a Logical Interface ove= r Multiple Physical Interfaces – Oct 2010  

Please consider this as an informative update for SA2 on the developments i= n NetExt WG in the IETF.

Best Regards,

IETF NetExt WG chairs             &nb= sp;        IETF Internet area director
Rajeev Koodli             &nb= sp;            =            Jari Arkko
Basavaraj Patil

--_000_BF345F63074F8040B58C00A186FCA57F1EFEFD6EA1NALASEXMB04na_-- From jouni.nospam@gmail.com Tue Apr 20 07:32:39 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B6028C191 for ; Tue, 20 Apr 2010 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=-1.512, BAYES_50=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogrY5FLMO81l for ; Tue, 20 Apr 2010 07:32:34 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id BB80328C1E0 for ; Tue, 20 Apr 2010 07:28:25 -0700 (PDT) Received: by bwz9 with SMTP id 9so5875980bwz.29 for ; Tue, 20 Apr 2010 07:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RJUW2PoRjjOaONEmcS6RenR1G2uXMLGG/acfClyai0g=; b=sgJEr1CuCNl5LlUdfxmjL7ifZtN4JsnmlVh0jLBMra7QCDMJCzeHRBfiphg4cEBHCs MmayFydpleL+Pit5wSPQF7/zcjl/xfPFSryvr7IC9DCS6CfkDvs6ZshUirrewU44U/YM hiKsaRZ0IL0JdT4nQVgnyaMKp5kxJctANSfRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=gpnrcFKrNDGn9gfVD9c8EnHH1HzLcpSm8ZIhpwz6+W+7guC0nb8FSowX2MsHamdD7t aEHesOAUTHFbMqoHjWUHpTeqprh9+kZ4CCUxV1gQa4WGqGAliPo55OHspSQr2k+cqTXc /YmFIzjdDnLJldi1U7l1zai4YFClK4JGon5K4= Received: by 10.86.221.34 with SMTP id t34mr5709891fgg.36.1271773693490; Tue, 20 Apr 2010 07:28:13 -0700 (PDT) Received: from a88-114-64-109.elisa-laajakaista.fi (a88-114-64-109.elisa-laajakaista.fi [88.114.64.109]) by mx.google.com with ESMTPS id y15sm3040418fkd.38.2010.04.20.07.28.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 07:28:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen X-Priority: 3 In-Reply-To: <01d301cae030$ae6b2570$23548a0a@china.huawei.com> Date: Tue, 20 Apr 2010 17:28:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4DC9B09C-C3D9-4208-BF47-74816A39CCCF@gmail.com> References: <002801cadc46$369ef910$23548a0a@china.huawei.com> <70F558D1-3955-4B70-9EB0-AC68A92D862D@gmail.com> <01d301cae030$ae6b2570$23548a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 14:32:39 -0000 Hi Qin, See my further comments inline. On Apr 20, 2010, at 5:25 AM, Qin Wu wrote: > Hi,Jouni: > ----- Original Message -----=20 > From: "jouni korhonen" > To: "Qin Wu" > Cc: > Sent: Saturday, April 17, 2010 12:01 AM > Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 >=20 >=20 > Hi Qin, >=20 > Thanks for the review! See my initial responses inline: >=20 > On Apr 15, 2010, at 5:49 AM, Qin Wu wrote: >=20 >> Hi, >> In Anaheim I volunteered to review this I-D. I think this I-D has = been in good shape. Here is my review of redirection document. >> = --------------------------------------------------------------------------= ------------------------------------------------------- >> In the section 1: >> o LMAs with multiple IP addresses: a cluster of LMAs or a blade >> architecture LMA may appear to the routing system as multiple = LMAs >> with separate unicast IP addresses. A MAG can initially select >> any of those LMA IP addresses as the LMA Address using e.g., = DNS- >> and AAA-based solutions. However, MAG's initial selection may = be >> suboptimal from the LMA point of view and immediate redirection = to >> a "proper LMA" would be needed. The LMA could use [RFC5142] = based >> approach but that would imply unnecessary setting up of a = mobility >> session in a "wrong LMA" with associated backend support system >> interactions, involve additional signaling between the MAG and = the >> LMA, and re-establishing mobility session to the new LMA again >> with associated signaling. >>=20 >> [Qin]: As described in [RFC5142], it seems changing the home = agent=20 >> of mobile node is mainly becos load balance consideration or = overloaded >> factor. Therefore not sure whether the bullet one(LMAs with = multiple IP >> address) overlaps with bulltet two(Bypassing a load balancer). >=20 > These are two different cases. Bullet one is about a wrong LMA = selection decision made by a MAG that needs to be "corrected" by a LMA.. = using excess signaling and unnecessary intermediate, yet complete, state = creation in a LMA. Bullet two is about how to avoid a load balancing = entity becoming a bottleneck. >=20 > [Qin]: Okay, Would you like to clarify in which scenario will the = wrong LMA selection happen? > a) In the exception case > In this case, why will MAG choose the wrong LMA? Typical example: load sharing based on DNS round-robin. LMA has no = proper way to feed up to date load information to global/local DNS so = that it would actually have any relevance (say.. caching times are too = long) or some vendor MAGs cache DNS responses outside the stub resolver. = Now it is rather likely that the LMA selected selected by the MAG is not = the most optimal seen by the "cluster" of LMAs. > b) load balance case > In this case, the candiate LMA to which the MAG is going to register = intend to offload to the other backup LMAs. Do you think this candidate = LMA can be looked as > wrong LMA? > c) or overloaded situation > In this case, the candiate LMA to which the MAG is going to register = is overloaded and need to transfer the load out.Do you think this = candidate LMA can be looked as > wrong LMA? I am slightly confused by the "candidate LMA" as I don't fully = understand what it means in this context. >=20 >> [Qin] In the section 5.4, it mentioned that Mobility Session can = be Created=20 >> After the Redirection. Not sure whether additional signaling = between the MAG >> and the redirected LMA is required? >=20 > If you are referring to RFC5142 here, then before you can do the HA = switch you need to setup a mobility session in both MAG and LMA before = you can actually send HA switch messages followed by closing the old = mobility session & creating a new one. Also, in real systems setting up = a mobility session in a LMA would involve a huge amount of additional = signaling toward subscriber management systems and such. These are = "additional signaling" what we want to avoid. >=20 > [Qin]: Thank for your clarification. That is to say, In contrast with = HA switch described in RFC5142, the Redirection mechanims descibeds in = the section 5.4 does not need additional > signaling to setup mobility session at the rfLMA.=20 >=20 >>=20 >> o Independence from DNS: DNS-based load balancing is a common >> practise. However, keeping MAGs up-to-date with LMA load status >> using DNS is hard e.g., due caching and unpredictable zone = update >> delays. Generally, LMAs constantly updating [RFC2136] zone's >> master DNS server might not feasible in a large PMIPv6 domain = due >> to increased load on the master DNS server and additional >> background signaling. Furthermore, MAGs may do (LMA) = destination >> address selection decisions that are not in-line what the DNS >> administrator actually wanted [RFC3484]. >>=20 >> [Qin]: Are you saying DNS-based LMA discovery is independent = from >> runtime LMA assignment described in this document? In some = cases, DNS-based >> LMA discovery may cost too much. Then we can choose runtime LMA = assignment instead of >> DNS-based approach.=20 >=20 > Hmm.. not entirely sure what you are after here. However, typical = DNS-based load balancing solutions just use a round-robin feature when = returning multiple A records, thus spreading load among a number of = LMAs. >=20 > The solution described in the draft does not need DNS for its load = balancing/redirection decision. Even if DNS pointed MAG to a certain = rfLMA, the rfLMA can still does a redirection decision independent what = DNS does.. >=20 > [Qin]: I agree. That is to say, Redirection based load balancing is = more effective and efficient than DNS-based load balancing.=20 >=20 >> If in this way, I am not really clear what the DNS-based load = balancing is here? >> Are you saying we need tradeoff between DNS based approach and = runtime LMA assignment? >=20 > See above. Also, we need a solution that does not depend on DNS at = all. >=20 > [Qin]: Okay, that is what you said in the draft. >=20 >>=20 >> o Independence from AAA: AAA-based solutions have basically the = same >> arguments as DNS-based solutions above. It is also typical that >> AAA-based solutions offload the initial LMA selection to the DNS >> infrastructure. The AAA infrastructure does not return an IP >> address or a Fully Qualified domain Name (FQDN) to a single LMA, >> rather a FQDN representing a group of LMAs. >>=20 >> [Qin] It is better to have references to AAA based solution and = DNS based solution. >=20 > Ok. What about: > AAA solution -> RFC5779 ? > DNS solution -> maybe ietf-draft-netlmm-lma-discovery ?? >=20 > [Qin]: Sounds good to me. >=20 >>=20 >> o Support for IPv6 anycast addressing [RFC4291]: the current = PMIPv6 >> specification does not specify how the PMIPv6 protocol should >> treat anycast addresses assigned to mobility agents. Although >> [RFC4291] now allows using anycast addresses as source = addresses, >> it does not make much sense using anycast addresses for the MAG = to >> the LMA communication after the initial PBU/PBA exchange. For >> example, a blade architecture LMA may appear to the routing = system >> as multiple LMAs with separate unicast IP addresses and with one >> or more "grouping" anycast addresses. =20 >>=20 >> [Qin]: Not sure [RFC4291] allow using anycast address as source = adresses or destination adress? >=20 >=20 > RFC4291 Appendix B first bullet says that anycast address restrictions = of RFC3515 were removed. In RFC3515 Section 2.6 use of anycast addresses = as a source address or as an address of an IPv6 host were explicitly = prohibited. >=20 > [Qin]: Thank for your clarification by providing references. I agree = it doesn't make sense when MAG use anycast address as source address. > However I am wondering whether it makes sense to use ancast address = for the LMA, in other words, when the MAG forwards the data to the LMA, = is it possible > for MAG to generate one data packet with anycast address of LMA as = destination address?=20 MAG would not use anycast address as a source address, rather as a = destination address for a LMA. The bullet above explains the use case = when anycast could be used. Probably the text is confusing. How about: o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 specification does not specify how the PMIPv6 protocol should treat anycast addresses assigned to mobility agents. For example, = a blade architecture LMA may appear to the routing system as = multiple LMAs with separate unicast IP addresses and with one or more = "grouping" anycast addresses. A MAG could then initially send a PBU to an = anycast LMA address and receive a PBA from an anycast LMA address. = Although [RFC4291] now allows using anycast addresses without restrictions, = it does not make much sense for MAGs and LMAs to continue using = anycast addresses beyond the initial PBU/PBA exchange but rather use node specific unicast addressing as soon as possible. >> [Qin]: I don't really understand what this paragraph want to = deliver? >> The mechanism for Runtime LMA assignment does not support = IPv6 anycast addressing? >> It seems this parpagraph is not the reason for using = runtime assignment? am I right? >=20 > Nop. A pool of (rf)LMAs may have anycast address. Once you contact = such LMA, you better be redirected to a unicast address of a LMA.. = otherwise stuff breaks. >=20 > [Qin]: I agree. But it seems a little confusing to use "Support for = IPv6 anycast addressing" as title of this bullet. People will thought = MAG or LMA can support IPv6 anycast=20 > addressing when communciation between MAG and LMA? am I right? See above. >=20 >>=20 >> In section 3: >> The LMA MUST NOT include the Redirect mobility option in the PBA = and >> perform the redirection, unless the MAG indicated the redirection >> functionality support in the corresponding PBU using the = Redirection- >> Capability mobility option. The LMA MUST NOT include the Redirect >> mobility option unsolicited even if the MAG had earlier indicated >> support for the redirection functionality. >>=20 >> [Qin] It seems to me that this assumption is too strict. What if = MAG and LMA have a prioor aggreement that >> MAG support Rediction functionality? >=20 > That is a normal way we indicate support for certain new features in = protocols. That allows mixing MAGs and LMAs e.g. with different software = releases in a PMIPv6 Domain. >=20 > [Qin]: Okay. >=20 >>=20 >>=20 >> In section 4.2: >>=20 >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Option Type | Option Length | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | IPv6 r2LMA Address | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Optional IPv4 r2LMA Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> Redirect Mobility Option >>=20 >> o Option Type: 8-bit identifier set to TBD2. >>=20 >> o Option Length: 8-bit unsigned integer, representing the length = of >> the Redirect mobility option in octets, excluding the Option = Type >> and Length fields. If the IPv4 LMA Address is included in the >> option, the Option Length MUST be set to 22. Otherwise, the >> Option Length MUST be set to 18. >>=20 >> o Reserved: This field is reserved for future use. MUST be set to >> zero. >>=20 >> o IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. >>=20 >> o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. = This >> value is present if the r2LMA IPv4 address is available. >>=20 >> [Qin]: I think whether IPv4 r2LMA address is included depends on=20= >> a) the r2LMA IPv4 address is available by rfLMA b) 'F'flag is set >> to 1 in the Redirect-Capability Mobility Option? what am I = missing? >=20 > You are right about the 'F' flag missing in the selection rule = description, thanks. Actually, this whole option has to be modified = slightly. The ipv4-support-18 now defines that in case of IPv4 transport = we do not carry IPv6 proxy-CoA and LMAA anywhere anymore. Effectively = this means the IPv6 r2LMA address should also be optional in Redirect = Mobility Option. The new Redirect Mobility option will have IPv6 LMAA or = IPv4 LMAA or both. >=20 > [Qin]: Good. >=20 >>=20 >> In section 6: >> A MN can be multi-homed. A single LMA entity should have the = control >> over all possible multi-homed mobility sessions the MN has. All >> mobility sessions a multi-homed MN may have SHOULD be anchored in = the >> single LMA entity. Therefore, once the MN has established one >> mobility session with one LMA, the subsequent mobility sessions of >> the same MN SHOULD be anchored to the LMA that was initially >> assigned. >> [Qin]: Little confused here. If MN has changed from=20 >> rfLMA to r2LMA, there are two choices ensuing : >> a) all the mobility sessions should be moved from rfLMA to r2LMA. >> b) all the mobility sessions will still stay at rfLMA? >> which one is correct? >=20 > c) all subsequent mobility sessions established for the same = multi-homed MN (independent which access/MAG/interface is used) should = to be created on the r2LMA that was initially assigned to the MN. >=20 > [Qin]: Good, I think that is reasonable to me. >=20 >>=20 >> One possible solution already supported by this specification is >> applying the redirection only for the very first initial attach a >> multi-homed MN does towards a PMIPv6 domain. After the initial >> attach, the assigned r2LMA Address has been stored in the policy >> profile. For the subsequent mobility sessions of the multi-homed = MN, >> the same assigned r2LMA Address would be used and there is no need = to >> contact the rfLMA. >>=20 >> [Qin]: What if r2LMA is overloaded again and need to rediret the = mobility session >> to another new r2LMA? >=20 > We do not support mid-session redirection by the request by the WG. = That means new mobility sessions for the same multi-homed MN will be = anchored to the existing r2LMA. If that fails due overload, then the new = mobility session gets rejected. >=20 > [Qin]: Okay. >=20 >>=20 >> In Section 8: >> If a PMIPv6 domain deployment with a redirection requires that a >> rfLMA has to modify a received PBU in any way e.g., by changing the >> destination IP address field of the outer IP header, then the >> security mechanism (such as possible authentication options) used = to >> protect the PBU must not cover the outer IP header on those parts >> that might get modified. Alternatively, the rfLMA can do all >> required security mechanism processing on the received PBU and = remove >> those security related options from the PBU that would cause the >> security check to fail on the r2LMA. >>=20 >> [Qin]: It seems to me changing the security part in the PBU is a = big challenging to runtime assignment. >> So I think maybe it is simpler to add another outer IP header which = may sacrifice some processing overheads at rfLMA. >=20 > I don't think so. When the rfLMA PMIPv6 "process" received the PBU, = IPsec or other security processing has already been done and the PMIPv6 = "process" sees the plain PBU. After that modifying PBU outer IP header = is no issue. Within a Redirection Domain there is no issue of rfLMA to = forward plain PBU to r2LMA. Alternatively, the rfLMA can re-protect the = PBU using the SA between rfLMA and r2LMA. This is bound to work, *if* = the PBU/PBA do not contain some authenticating mobility option covering = also outer transport IP headers. Whatever happens here is transparent to = MAG or r2LMA. >=20 > [Qin]; Okay, Does it mean only transport mode ESP can be used to = protect PBU exchanged between MAG and rfLMA if IPSEC protection is = employed and there are some authentication mobility option in such PBU. = Becos in the AH or tunnel mode ESP, the outer IP header will be = protected. am I right? Tunnel mode ESP is fine. Tunnel mode ESP does not cover outer tunneling = IP header. AH has issues but then again, who even uses AH? The bigger = problem would actually be possible security options that are mobility = options and cover also e.g. some kind of pseudo header of the original = encapsulating packet. Such options would break what we are doing here. > As regarding to what security mechanism can be used between rfLMA and = r2LMA, if we assume plain PBU is protected by transport mode ESP,=20 > then whatever security mechanism is used does not matter, Since it has = been assumed that there are trust relationship between rfLMA and r2LMA. - Jouni >=20 >=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From ahmad.muhanna@ericsson.com Tue Apr 20 07:39:02 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AB33A69BD for ; Tue, 20 Apr 2010 07:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6QbJrjpA1xZ for ; Tue, 20 Apr 2010 07:38:58 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D079728C0FF for ; Tue, 20 Apr 2010 07:38:23 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o3KEgkjt006666; Tue, 20 Apr 2010 09:42:50 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.178]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 20 Apr 2010 10:38:10 -0400 From: Ahmad Muhanna To: "Laganier, Julien" , Rajeev Koodli , "netext@ietf.org" Date: Tue, 20 Apr 2010 10:38:09 -0400 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOA= Message-ID: <1FCAE7B6027FE3489B8497A060C704C4261B8EB68C@EUSAACMS0714.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1FCAE7B6027FE3489B8497A060C704C4261B8EB68CEUSAACMS0714e_" MIME-Version: 1.0 Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 14:39:02 -0000 --_000_1FCAE7B6027FE3489B8497A060C704C4261B8EB68CEUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition; Is NOT there a semi-regular conference call with 3GPP to updat= e on the status of IETF documents that is referenced and needed for 3GPP? I am also wondering as well, what this LS will buy either side? Regards, Ahmad ________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Laganier, Julien Sent: Tuesday, April 20, 2010 9:00 AM To: Rajeev Koodli; netext@ietf.org Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP Hello Rajeev, I am unfamiliar with an IETF WG spontaneously generating a Liaison Statemen= ts to another organization -- Given that a contribution S2-101433 (link bel= ow) from Cisco and Intel was discussed at the last physical 3GPP SA2 WG mee= ting in San Francisco and already outlined in a much detailed fashion that = the IETF NETEXT WG was rechartered to work on PMIPv6 flow mobility, I am wo= ndering what would be the intended outcome of sending such an LS. --julien From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of= Rajeev Koodli Sent: Monday, April 19, 2010 12:32 PM To: netext@ietf.org Subject: [netext] Liaison Statement on Flow Mobility to 3GPP FYI..Jari and the chairs are planning to send the following LS to 3GPP info= rming them of NetExt's work on Flow Mobility. Please provide comments, if any.. Thanks, -Rajeev .................................... April 14, 2010 To: 3GPP SA2 Chairman: Balazs Bertenyi Vice chairman: Andy Bennett Vice chairman: Hong Liu Subject: Flow mobility feature being specified for Proxy Mobile IPv6 (RFC5= 213) in the NetExt WG Dear Balazs, Andy and, Hong, We would like to inform you about the work being done on extending Proxy Mo= bile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the IE= TF. The NetExt WG charter was revised and approved in February 2010 with th= e following new goal and milestone: 1. Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flo= w Mobility and Inter-access Handovers on a Logical Interface over Multiple = Physical Interfaces - Oct 2010 Please consider this as an informative update for SA2 on the developments i= n NetExt WG in the IETF. Best Regards, IETF NetExt WG chairs IETF Internet area director Rajeev Koodli Jari Arkko Basavaraj Patil --_000_1FCAE7B6027FE3489B8497A060C704C4261B8EB68CEUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Liaison Sta= tement on Flow Mobility to 3GPP
In addition; Is NOT there a semi-regular conferenc= e call=20 with 3GPP to update on the status of IETF documents that is referenced and= =20 needed for 3GPP?
 
I am also wondering as well, what this LS will buy= either=20 side?
 
Regards,
Ahmad
From: netext-bounces@ietf.org=20 [mailto:netext-bounces@ietf.org] On Behalf Of Laganier,=20 Julien
Sent: Tuesday, April 20, 2010 9:00 AM
To: Rajeev= =20 Koodli; netext@ietf.org
Subject: Re: [netext] Liaison Statement o= n=20 Flow Mobility to 3GPP

Hello=20 Rajeev,

I=20 am unfamiliar with an IETF WG spontaneously generating a Liaison Statements= to=20 another organization -- Given that a contribution S2-101433 (link below) fr= om=20 Cisco and Intel was discussed at the last physical 3GPP SA2 WG meeting in S= an=20 Francisco and already outlined in a much detailed fashion that the IETF NET= EXT=20 WG was rechartered to work on PMIPv6 flow mobility, I am wondering what wou= ld be=20 the intended outcome of sending such an LS.

<ftp://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_78_San_Francisco/Docs/S= 2-101433.zip>

--julien

 

From:<= /B>=20 netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of=20 Rajeev Koodli
Sent: Monday, April 19, 2010 12:32 PM
To:= =20 netext@ietf.org
Subject: [netext] Liaison Statement on Flow Mobil= ity=20 to 3GPP

 


FYI..Jar= i and=20 the chairs are planning to send the following LS to 3GPP informing them of= =20 NetExt’s work on Flow Mobility.
Please provide comments, if=20 any..

Thanks,

-Rajeev
....................................=
 

April 14, 2010
 
To: 3GPP=20 SA2
           &n= bsp;      Chairman:=20 Balazs=20 Bertenyi
          &nb= sp;       Vice=20 chairman: Andy=20 Bennett
          &nbs= p;       Vice=20 chairman: Hong Liu
 
Subject:  Flow mobility feature bei= ng=20 specified for Proxy Mobile IPv6 (RFC5213) in the NetExt WG

Dear= =20 Balazs, Andy and, Hong,

We would like to inform you about the work b= eing=20 done on extending Proxy Mobile IPv6 (RFC5213) to support flow mobility with= in=20 the NetExt WG in the IETF. The NetExt WG charter was revised and approved i= n=20 February 2010 with the following new goal and milestone:

1.=20    Initial WG document(s) on Proxy Mobile IPv6 Extensions to= =20 Support Flow Mobility and Inter-access Handovers on a Logical Interface ove= r=20 Multiple Physical Interfaces – Oct 2010  

Please consider= this as an=20 informative update for SA2 on the developments in NetExt WG in the=20 IETF.

Best Regards,

IETF NetExt WG chairs=20             &nb= sp;        IETF=20 Internet area director
Rajeev Koodli=20             &nb= sp;            =            Jari=20 Arkko
Basavaraj Patil

--_000_1FCAE7B6027FE3489B8497A060C704C4261B8EB68CEUSAACMS0714e_-- From rkoodli@cisco.com Tue Apr 20 12:54:47 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE9A3A6A97 for ; Tue, 20 Apr 2010 12:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.805 X-Spam-Level: X-Spam-Status: No, score=-8.805 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x4uHlHoB-jj for ; Tue, 20 Apr 2010 12:54:40 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5C86F3A6946 for ; Tue, 20 Apr 2010 12:54:40 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8GAK+jzUutJV2a/2dsb2JhbACBP5l4VXGjBJpGhQ8EgzSHGw X-IronPort-AV: E=Sophos;i="4.52,244,1270425600"; d="scan'208,217";a="103391228" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2010 19:54:21 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o3KJsGPm032347; Tue, 20 Apr 2010 19:54:16 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Apr 2010 15:51:49 -0400 Received: from 10.21.168.27 ([10.21.168.27]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Apr 2010 19:51:49 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 20 Apr 2010 12:56:04 -0700 From: Rajeev Koodli To: Ahmad Muhanna , "Laganier, Julien" , "netext@ietf.org" Message-ID: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQ== In-Reply-To: <1FCAE7B6027FE3489B8497A060C704C4261B8EB68C@EUSAACMS0714.eamcs.ericsson.se> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3354612964_39252277" X-OriginalArrivalTime: 20 Apr 2010 19:51:49.0958 (UTC) FILETIME=[EAB66660:01CAE0C2] Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 19:54:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3354612964_39252277 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Julien, Ahmad, this LS is informative. It is making it known (officially from IETF perspective, if you will) that the NetExt WG is working on Flow Mobility for PMIP6. We have heard some arguments in 3GPP that status of this work in IETF is unclear. This is making it clear and official, that's all. Regards, -Rajeev On 4/20/10 7:38 AM, "Ahmad Muhanna" wrote: > In addition; Is NOT there a semi-regular conference call with 3GPP to upd= ate > on the status of IETF documents that is referenced and needed for 3GPP? > =20 > I am also wondering as well, what this LS will buy either side? > =20 > Regards,=20 > Ahmad=20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Laganier, Julien > Sent: Tuesday, April 20, 2010 9:00 AM > To: Rajeev Koodli; netext@ietf.org > Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP >=20 > Hello Rajeev, > I am unfamiliar with an IETF WG spontaneously generating a Liaison Statem= ents > to another organization -- Given that a contribution S2-101433 (link belo= w) > from Cisco and Intel was discussed at the last physical 3GPP SA2 WG meeti= ng in > San Francisco and already outlined in a much detailed fashion that the IE= TF > NETEXT WG was rechartered to work on PMIPv6 flow mobility, I am wondering= what > would be the intended outcome of sending such an LS. > > --julien > =20 >=20 > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of > Rajeev Koodli > Sent: Monday, April 19, 2010 12:32 PM > To: netext@ietf.org > Subject: [netext] Liaison Statement on Flow Mobility to 3GPP > =20 >=20 > FYI..Jari and the chairs are planning to send the following LS to 3GPP > informing them of NetExt=B9s work on Flow Mobility. > Please provide comments, if any.. >=20 > Thanks, >=20 > -Rajeev > .................................... > =20 >=20 > April 14, 2010 > =20 > To: 3GPP SA2 > Chairman: Balazs Bertenyi > Vice chairman: Andy Bennett > Vice chairman: Hong Liu > =20 > Subject: Flow mobility feature being specified for Proxy Mobile IPv6 > (RFC5213) in the NetExt WG >=20 > Dear Balazs, Andy and, Hong, >=20 > We would like to inform you about the work being done on extending Proxy > Mobile IPv6 (RFC5213) to support flow mobility within the NetExt WG in th= e > IETF. The NetExt WG charter was revised and approved in February 2010 wit= h the > following new goal and milestone: >=20 > 1. Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support F= low > Mobility and Inter-access Handovers on a Logical Interface over Multiple > Physical Interfaces =AD Oct 2010 >=20 > Please consider this as an informative update for SA2 on the developments= in > NetExt WG in the IETF. >=20 > Best Regards, >=20 > IETF NetExt WG chairs IETF Internet area director > Rajeev Koodli Jari Arkko > Basavaraj Patil >=20 --B_3354612964_39252277 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Liaison Statement on Flow Mobility to 3GPP
Hi Julien, Ahmad,

this LS is informative. It is making it known (officially from IETF
perspective, if you will) that the NetExt WG is working on Flow Mobility for PMIP6.

We have heard some arguments in 3GPP that status of this work in
IETF is unclear. This is making it clear and official, that's all.

Regards,

-Rajeev


On 4/20/10 7:38 AM, "Ahmad Muhanna" <ahmad.muhanna@ericsson.com> wrote:

In addition; Is NOT there a semi-regular conference cal= l with 3GPP to update on the status of IETF documents that is referenced and= needed for 3GPP?
I am also wondering as well= , what this LS will buy either side?
Regards,
Ahmad
From: netext-boun= ces@ietf.org [mailto:netext-bou= nces@ietf.org] On Behalf Of Laganier, Julien
Sent: Tuesday, April 20, 2010 9:00 AM
To: Rajeev Koodli; netext@ietf.org
Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP

Hello Rajeev,
I am unfamiliar with an IETF WG spontaneously generating a Liaison Statemen= ts to another organization -- Given that a contribution S2-101433 (link belo= w) from Cisco and Intel was discussed at the last physical 3GPP SA2 WG meeti= ng in San Francisco and already outlined in a much detailed fashion that the= IETF NETEXT WG was rechartered to work on PMIPv6 flow mobility, I am wonder= ing what would be the intended outcome of sending such an LS.
<ftp://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_78_San_Francisco= /Docs/S2-101433.zip>
--julien
 

From: netext-bounces@ietf.org [mailt= o:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Monday, April 19, 2010 12:32 PM
To: netext@ietf.org
Subject: [netext] Liaison Statement on Flow Mobility to 3GPP

FYI..Jari and the chairs are planning to send the following LS to 3GPP info= rming them of NetExt’s work on Flow Mobility.
Please provide comments, if any..

Thanks,

-Rajeev
....................................
 

Apr= il 14, 2010
 
To: 3GPP SA2
            &nb= sp;     Chairman: Balazs Bertenyi
            &nb= sp;     Vice chairman: Andy Bennett
            &nb= sp;     Vice chairman: Hong Liu
 
Subject:  Flow mobility feature being specified for Proxy Mobile IP= v6 (RFC5213) in the NetExt WG

Dear Balazs, Andy and, Hong,

We would like to inform you about the work being done on extending Proxy Mo= bile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the IET= F. The NetExt WG charter was revised and approved in February 2010 with the = following new goal and milestone:

1.    Initial WG document(s) on Proxy Mobile IPv6 Extensions= to Support Flow Mobility and Inter-access Handovers on a Logical Interface = over Multiple Physical Interfaces – Oct 2010  

Please consider this as an informative update for SA2 on the developments i= n NetExt WG in the IETF.

Best Regards,

IETF NetExt WG chairs          = ;            IET= F Internet area director
Rajeev Koodli           &= nbsp;            = ;            &nb= sp;Jari Arkko
Basavaraj Patil

--B_3354612964_39252277-- From sunseawq@huawei.com Wed Apr 21 04:04:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B0628C0DB for ; Wed, 21 Apr 2010 04:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.671 X-Spam-Level: ** X-Spam-Status: No, score=2.671 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQBDlB-c1xq1 for ; Wed, 21 Apr 2010 04:04:06 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CEA5A28C130 for ; Wed, 21 Apr 2010 04:03:45 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1800C4241P2N@szxga03-in.huawei.com> for netext@ietf.org; Wed, 21 Apr 2010 19:03:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1800BAB41PY1@szxga03-in.huawei.com> for netext@ietf.org; Wed, 21 Apr 2010 19:03:25 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L180020Z41PWC@szxml06-in.huawei.com> for netext@ietf.org; Wed, 21 Apr 2010 19:03:25 +0800 (CST) Date: Wed, 21 Apr 2010 19:03:23 +0800 From: Qin Wu To: jouni korhonen Message-id: <003901cae142$42e893b0$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002801cadc46$369ef910$23548a0a@china.huawei.com> <70F558D1-3955-4B70-9EB0-AC68A92D862D@gmail.com> <01d301cae030$ae6b2570$23548a0a@china.huawei.com> <4DC9B09C-C3D9-4208-BF47-74816A39CCCF@gmail.com> Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:04:08 -0000 Hi, Jouni: ----- Original Message ----- From: "jouni korhonen" To: "Qin Wu" Cc: Sent: Tuesday, April 20, 2010 10:28 PM Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 Hi Qin, See my further comments inline. On Apr 20, 2010, at 5:25 AM, Qin Wu wrote: > Hi,Jouni: > ----- Original Message ----- > From: "jouni korhonen" > To: "Qin Wu" > Cc: > Sent: Saturday, April 17, 2010 12:01 AM > Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 > > > Hi Qin, > > Thanks for the review! See my initial responses inline: > > On Apr 15, 2010, at 5:49 AM, Qin Wu wrote: > >> Hi, >> In Anaheim I volunteered to review this I-D. I think this I-D has been in good shape. Here is my review of redirection document. >> --------------------------------------------------------------------------------------------------------------------------------- >> In the section 1: >> o LMAs with multiple IP addresses: a cluster of LMAs or a blade >> architecture LMA may appear to the routing system as multiple LMAs >> with separate unicast IP addresses. A MAG can initially select >> any of those LMA IP addresses as the LMA Address using e.g., DNS- >> and AAA-based solutions. However, MAG's initial selection may be >> suboptimal from the LMA point of view and immediate redirection to >> a "proper LMA" would be needed. The LMA could use [RFC5142] based >> approach but that would imply unnecessary setting up of a mobility >> session in a "wrong LMA" with associated backend support system >> interactions, involve additional signaling between the MAG and the >> LMA, and re-establishing mobility session to the new LMA again >> with associated signaling. >> >> [Qin]: As described in [RFC5142], it seems changing the home agent >> of mobile node is mainly becos load balance consideration or overloaded >> factor. Therefore not sure whether the bullet one(LMAs with multiple IP >> address) overlaps with bulltet two(Bypassing a load balancer). > > These are two different cases. Bullet one is about a wrong LMA selection decision made by a MAG that needs to be "corrected" by a LMA.. using excess signaling and unnecessary intermediate, yet complete, state creation in a LMA. Bullet two is about how to avoid a load balancing entity becoming a bottleneck. > > [Qin]: Okay, Would you like to clarify in which scenario will the wrong LMA selection happen? > a) In the exception case > In this case, why will MAG choose the wrong LMA? Typical example: load sharing based on DNS round-robin. LMA has no proper way to feed up to date load information to global/local DNS so that it would actually have any relevance (say.. caching times are too long) or some vendor MAGs cache DNS responses outside the stub resolver. Now it is rather likely that the LMA selected selected by the MAG is not the most optimal seen by the "cluster" of LMAs. [Qin]: Thank for your clarification. That is to say, If MAG choose the out of date LMA using DNS based LMA discovery, it may result in sub-optimal LMA selection. This sub-optimal LMA can be looked as "wrong LMA". Right? > b) load balance case > In this case, the candiate LMA to which the MAG is going to register intend to offload to the other backup LMAs. Do you think this candidate LMA can be looked as > wrong LMA? > c) or overloaded situation > In this case, the candiate LMA to which the MAG is going to register is overloaded and need to transfer the load out.Do you think this candidate LMA can be looked as > wrong LMA? I am slightly confused by the "candidate LMA" as I don't fully understand what it means in this context. [Qin]: I just try to figure out how to understand "wrong LMA" and what cause wrong LMA selection. I think if DNS based LMA discovery only provides sub-optimal LMA or out of date LMA, we can use Redirection mechanism described in the draft-ietf-netext-redirect to re-choose the best choice or optimal LMA for the MAG. But when MAG obtain one new LMA using DNS based approach, I believe the MAG didn't know if this LMA obtained using DNS is optimal LMA or wrong LMA. Only when MAG register to this new LMA by sending PBU, this new LMA can tell the MAG whether the LMA chosed by MAG is the optimal LMA. So what is the criterial to judge whether the LMA is wrong LMA or optimal LMA? I think the only criteria is look at whether the new LMA is overloaded or need to do load balance. In summary: 1) I think the MAG can not know if the LMA obtained using DNS is the wrong LMA. Only the LMA itself know. 2) The only criteria to judge if the LMA is the wrong LMA is based on load balance consideration. >> [Qin] In the section 5.4, it mentioned that Mobility Session can be Created >> After the Redirection. Not sure whether additional signaling between the MAG >> and the redirected LMA is required? > > If you are referring to RFC5142 here, then before you can do the HA switch you need to setup a mobility session in both MAG and LMA before you can actually send HA switch messages followed by closing the old mobility session & creating a new one. Also, in real systems setting up a mobility session in a LMA would involve a huge amount of additional signaling toward subscriber management systems and such. These are "additional signaling" what we want to avoid. > > [Qin]: Thank for your clarification. That is to say, In contrast with HA switch described in RFC5142, the Redirection mechanims descibeds in the section 5.4 does not need additional > signaling to setup mobility session at the rfLMA. > >> >> o Independence from DNS: DNS-based load balancing is a common >> practise. However, keeping MAGs up-to-date with LMA load status >> using DNS is hard e.g., due caching and unpredictable zone update >> delays. Generally, LMAs constantly updating [RFC2136] zone's >> master DNS server might not feasible in a large PMIPv6 domain due >> to increased load on the master DNS server and additional >> background signaling. Furthermore, MAGs may do (LMA) destination >> address selection decisions that are not in-line what the DNS >> administrator actually wanted [RFC3484]. >> >> [Qin]: Are you saying DNS-based LMA discovery is independent from >> runtime LMA assignment described in this document? In some cases, DNS-based >> LMA discovery may cost too much. Then we can choose runtime LMA assignment instead of >> DNS-based approach. > > Hmm.. not entirely sure what you are after here. However, typical DNS-based load balancing solutions just use a round-robin feature when returning multiple A records, thus spreading load among a number of LMAs. > > The solution described in the draft does not need DNS for its load balancing/redirection decision. Even if DNS pointed MAG to a certain rfLMA, the rfLMA can still does a redirection decision independent what DNS does.. > > [Qin]: I agree. That is to say, Redirection based load balancing is more effective and efficient than DNS-based load balancing. > >> If in this way, I am not really clear what the DNS-based load balancing is here? >> Are you saying we need tradeoff between DNS based approach and runtime LMA assignment? > > See above. Also, we need a solution that does not depend on DNS at all. > > [Qin]: Okay, that is what you said in the draft. > >> >> o Independence from AAA: AAA-based solutions have basically the same >> arguments as DNS-based solutions above. It is also typical that >> AAA-based solutions offload the initial LMA selection to the DNS >> infrastructure. The AAA infrastructure does not return an IP >> address or a Fully Qualified domain Name (FQDN) to a single LMA, >> rather a FQDN representing a group of LMAs. >> >> [Qin] It is better to have references to AAA based solution and DNS based solution. > > Ok. What about: > AAA solution -> RFC5779 ? > DNS solution -> maybe ietf-draft-netlmm-lma-discovery ?? > > [Qin]: Sounds good to me. > >> >> o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 >> specification does not specify how the PMIPv6 protocol should >> treat anycast addresses assigned to mobility agents. Although >> [RFC4291] now allows using anycast addresses as source addresses, >> it does not make much sense using anycast addresses for the MAG to >> the LMA communication after the initial PBU/PBA exchange. For >> example, a blade architecture LMA may appear to the routing system >> as multiple LMAs with separate unicast IP addresses and with one >> or more "grouping" anycast addresses. >> >> [Qin]: Not sure [RFC4291] allow using anycast address as source adresses or destination adress? > > > RFC4291 Appendix B first bullet says that anycast address restrictions of RFC3515 were removed. In RFC3515 Section 2.6 use of anycast addresses as a source address or as an address of an IPv6 host were explicitly prohibited. > > [Qin]: Thank for your clarification by providing references. I agree it doesn't make sense when MAG use anycast address as source address. > However I am wondering whether it makes sense to use ancast address for the LMA, in other words, when the MAG forwards the data to the LMA, is it possible > for MAG to generate one data packet with anycast address of LMA as destination address? MAG would not use anycast address as a source address, rather as a destination address for a LMA. The bullet above explains the use case when anycast could be used. Probably the text is confusing. How about: o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 specification does not specify how the PMIPv6 protocol should treat anycast addresses assigned to mobility agents. For example, a blade architecture LMA may appear to the routing system as multiple LMAs with separate unicast IP addresses and with one or more "grouping" anycast addresses. A MAG could then initially send a PBU to an anycast LMA address and receive a PBA from an anycast LMA address. Although [RFC4291] now allows using anycast addresses without restrictions, it does not make much sense for MAGs and LMAs to continue using anycast addresses beyond the initial PBU/PBA exchange but rather use node specific unicast addressing as soon as possible. [Qin]: Good. I am okay with your change. >> [Qin]: I don't really understand what this paragraph want to deliver? >> The mechanism for Runtime LMA assignment does not support IPv6 anycast addressing? >> It seems this parpagraph is not the reason for using runtime assignment? am I right? > > Nop. A pool of (rf)LMAs may have anycast address. Once you contact such LMA, you better be redirected to a unicast address of a LMA.. otherwise stuff breaks. > > [Qin]: I agree. But it seems a little confusing to use "Support for IPv6 anycast addressing" as title of this bullet. People will thought MAG or LMA can support IPv6 anycast > addressing when communciation between MAG and LMA? am I right? See above. > >> >> In section 3: >> The LMA MUST NOT include the Redirect mobility option in the PBA and >> perform the redirection, unless the MAG indicated the redirection >> functionality support in the corresponding PBU using the Redirection- >> Capability mobility option. The LMA MUST NOT include the Redirect >> mobility option unsolicited even if the MAG had earlier indicated >> support for the redirection functionality. >> >> [Qin] It seems to me that this assumption is too strict. What if MAG and LMA have a prioor aggreement that >> MAG support Rediction functionality? > > That is a normal way we indicate support for certain new features in protocols. That allows mixing MAGs and LMAs e.g. with different software releases in a PMIPv6 Domain. > > [Qin]: Okay. > >> >> >> In section 4.2: >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Option Type | Option Length | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | IPv6 r2LMA Address | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Optional IPv4 r2LMA Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Redirect Mobility Option >> >> o Option Type: 8-bit identifier set to TBD2. >> >> o Option Length: 8-bit unsigned integer, representing the length of >> the Redirect mobility option in octets, excluding the Option Type >> and Length fields. If the IPv4 LMA Address is included in the >> option, the Option Length MUST be set to 22. Otherwise, the >> Option Length MUST be set to 18. >> >> o Reserved: This field is reserved for future use. MUST be set to >> zero. >> >> o IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. >> >> o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This >> value is present if the r2LMA IPv4 address is available. >> >> [Qin]: I think whether IPv4 r2LMA address is included depends on >> a) the r2LMA IPv4 address is available by rfLMA b) 'F'flag is set >> to 1 in the Redirect-Capability Mobility Option? what am I missing? > > You are right about the 'F' flag missing in the selection rule description, thanks. Actually, this whole option has to be modified slightly. The ipv4-support-18 now defines that in case of IPv4 transport we do not carry IPv6 proxy-CoA and LMAA anywhere anymore. Effectively this means the IPv6 r2LMA address should also be optional in Redirect Mobility Option. The new Redirect Mobility option will have IPv6 LMAA or IPv4 LMAA or both. > > [Qin]: Good. > >> >> In section 6: >> A MN can be multi-homed. A single LMA entity should have the control >> over all possible multi-homed mobility sessions the MN has. All >> mobility sessions a multi-homed MN may have SHOULD be anchored in the >> single LMA entity. Therefore, once the MN has established one >> mobility session with one LMA, the subsequent mobility sessions of >> the same MN SHOULD be anchored to the LMA that was initially >> assigned. >> [Qin]: Little confused here. If MN has changed from >> rfLMA to r2LMA, there are two choices ensuing : >> a) all the mobility sessions should be moved from rfLMA to r2LMA. >> b) all the mobility sessions will still stay at rfLMA? >> which one is correct? > > c) all subsequent mobility sessions established for the same multi-homed MN (independent which access/MAG/interface is used) should to be created on the r2LMA that was initially assigned to the MN. > > [Qin]: Good, I think that is reasonable to me. > >> >> One possible solution already supported by this specification is >> applying the redirection only for the very first initial attach a >> multi-homed MN does towards a PMIPv6 domain. After the initial >> attach, the assigned r2LMA Address has been stored in the policy >> profile. For the subsequent mobility sessions of the multi-homed MN, >> the same assigned r2LMA Address would be used and there is no need to >> contact the rfLMA. >> >> [Qin]: What if r2LMA is overloaded again and need to rediret the mobility session >> to another new r2LMA? > > We do not support mid-session redirection by the request by the WG. That means new mobility sessions for the same multi-homed MN will be anchored to the existing r2LMA. If that fails due overload, then the new mobility session gets rejected. > > [Qin]: Okay. > >> >> In Section 8: >> If a PMIPv6 domain deployment with a redirection requires that a >> rfLMA has to modify a received PBU in any way e.g., by changing the >> destination IP address field of the outer IP header, then the >> security mechanism (such as possible authentication options) used to >> protect the PBU must not cover the outer IP header on those parts >> that might get modified. Alternatively, the rfLMA can do all >> required security mechanism processing on the received PBU and remove >> those security related options from the PBU that would cause the >> security check to fail on the r2LMA. >> >> [Qin]: It seems to me changing the security part in the PBU is a big challenging to runtime assignment. >> So I think maybe it is simpler to add another outer IP header which may sacrifice some processing overheads at rfLMA. > > I don't think so. When the rfLMA PMIPv6 "process" received the PBU, IPsec or other security processing has already been done and the PMIPv6 "process" sees the plain PBU. After that modifying PBU outer IP header is no issue. Within a Redirection Domain there is no issue of rfLMA to forward plain PBU to r2LMA. Alternatively, the rfLMA can re-protect the PBU using the SA between rfLMA and r2LMA. This is bound to work, *if* the PBU/PBA do not contain some authenticating mobility option covering also outer transport IP headers. Whatever happens here is transparent to MAG or r2LMA. > > [Qin]; Okay, Does it mean only transport mode ESP can be used to protect PBU exchanged between MAG and rfLMA if IPSEC protection is employed and there are some authentication mobility option in such PBU. Becos in the AH or tunnel mode ESP, the outer IP header will be protected. am I right? Tunnel mode ESP is fine. Tunnel mode ESP does not cover outer tunneling IP header. AH has issues but then again, who even uses AH? The bigger problem would actually be possible security options that are mobility options and cover also e.g. some kind of pseudo header of the original encapsulating packet. Such options would break what we are doing here. [Qin] Thank for correcting me, I agree. > As regarding to what security mechanism can be used between rfLMA and r2LMA, if we assume plain PBU is protected by transport mode ESP, > then whatever security mechanism is used does not matter, Since it has been assumed that there are trust relationship between rfLMA and r2LMA. - Jouni > > >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Wed Apr 21 08:11:29 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342CA28C353 for ; Wed, 21 Apr 2010 08:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyec3Tz0k6ho for ; Wed, 21 Apr 2010 08:11:24 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7B07228C428 for ; Wed, 21 Apr 2010 07:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1271861356; x=1303397356; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Rajeev=20Koodli=20,=20Ahmad=20M uhanna=0D=0A=09,=20"netext@ie tf.org"=20|Date:=20Wed,=2021=20Apr=20201 0=2007:49:12=20-0700|Subject:=20RE:=20[netext]=20Liaison =20Statement=20on=20Flow=20Mobility=20to=203GPP |Thread-Topic:=20[netext]=20Liaison=20Statement=20on=20Fl ow=20Mobility=20to=203GPP|Thread-Index:=20Acrf9vKv/KT/1NV EMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIw|Message-ID:=20< BF345F63074F8040B58C00A186FCA57F1EFEFD6FD5@NALASEXMB04.na .qualcomm.com>|References:=20<1FCAE7B6027FE3489B8497A060C 704C4261B8EB68C@EUSAACMS0714.eamcs.ericsson.se>=0D=0A=20< C7F354E4.5498%rkoodli@cisco.com>|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=8vPaN27GKNcsnmyp5UoIowWWoTlouXNRo52iCy+Aeak=; b=oimsNvHWs9cELm9yj7q8cOaAleqAEUq32yFfY5XbBWYRBS/UJA9nUQl6 B6gfvj/JEGgub9e41FD40hyY8idsVbUEe47yHZ4PSjNAmRKA7GJfNwBlN csBeotcy9bngmYbRT+TlNQvM1xo1lOsfQJclLN+U6sIAYXXDlSTQPM/tN o=; X-IronPort-AV: E=McAfee;i="5400,1158,5958"; a="39356763" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 21 Apr 2010 07:49:15 -0700 X-IronPort-AV: E=Sophos;i="4.52,247,1270450800"; d="scan'208";a="13419623" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Apr 2010 07:49:15 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 21 Apr 2010 07:49:15 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 21 Apr 2010 07:49:15 -0700 From: "Laganier, Julien" To: Rajeev Koodli , Ahmad Muhanna , "netext@ietf.org" Date: Wed, 21 Apr 2010 07:49:12 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIw Message-ID: References: <1FCAE7B6027FE3489B8497A060C704C4261B8EB68C@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 15:11:29 -0000 Hi Rajeev, I am still not sure why we are spontaneously sending an LS to 3GPP... Rajeev Koodli wrote: > > Hi Julien, Ahmad, >=20 > this LS is informative. It is making it known (officially from IETF > perspective, if you will) that the NetExt WG is working on Flow Mobility > for PMIP6. > > We have heard some arguments in 3GPP that status of this work in > IETF is unclear.=20 Who is we in "we have heard ..."? Also - how can the status of this work in the IETF be unclear when it is ex= plicitly listed on the NETEXT WG charter? > This is making it clear and official, that's all. If 3GPP is wondering what is the official status of this work in IETF, why = don't they read the NETEXT charter? Best, --julien From Basavaraj.Patil@nokia.com Wed Apr 21 10:07:13 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82893A69FD for ; Wed, 21 Apr 2010 10:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpZZAbL+Rcyq for ; Wed, 21 Apr 2010 10:07:12 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id F29C53A6B7E for ; Wed, 21 Apr 2010 09:53:06 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3LGqov8025243; Wed, 21 Apr 2010 19:52:51 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 19:52:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 19:52:09 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 21 Apr 2010 18:52:08 +0200 From: To: , , , Date: Wed, 21 Apr 2010 18:52:05 +0200 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIwACuvCEY= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2010 16:52:09.0475 (UTC) FILETIME=[FB74FD30:01CAE172] X-Nokia-AV: Clean Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:07:13 -0000 Julien, There is no harm in sending the LS. It is informative. While SA2 can just a= s well read the text of the Netext charter, we do have a channel to provide such informative updates through liason statements and we are simply using that.=20 -Raj On 4/21/10 9:49 AM, "ext Laganier, Julien" wrote: > Hi Rajeev, >=20 > I am still not sure why we are spontaneously sending an LS to 3GPP... >=20 > Rajeev Koodli wrote: >>=20 >> Hi Julien, Ahmad, >>=20 >> this LS is informative. It is making it known (officially from IETF >> perspective, if you will) that the NetExt WG is working on Flow Mobility >> for PMIP6. >>=20 >> We have heard some arguments in 3GPP that status of this work in >> IETF is unclear. >=20 > Who is we in "we have heard ..."? >=20 > Also - how can the status of this work in the IETF be unclear when it is > explicitly listed on the NETEXT WG charter? >=20 >> This is making it clear and official, that's all. >=20 > If 3GPP is wondering what is the official status of this work in IETF, wh= y > don't they read the NETEXT charter? >=20 > Best, >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From ahmad.muhanna@ericsson.com Wed Apr 21 10:29:02 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E1A3A6934 for ; Wed, 21 Apr 2010 10:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHooWJlKtYrk for ; Wed, 21 Apr 2010 10:29:01 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 730693A6359 for ; Wed, 21 Apr 2010 10:17:13 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3LHGa1A017512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Apr 2010 12:17:02 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.178]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 21 Apr 2010 13:16:54 -0400 From: Ahmad Muhanna To: "Basavaraj.Patil@nokia.com" , "julienl@qualcomm.com" , "rkoodli@cisco.com" , "netext@ietf.org" Date: Wed, 21 Apr 2010 13:16:53 -0400 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIwACuvCEYAAIMYQA== Message-ID: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:29:02 -0000 Hi Raj, I think we are setting a precedence here. I am not aware of IETF sending un= solicited LSes; but I could be wrong. On the other hand, I understand other SDOs sending an LS to IETF requesting= IETF to work on a specific topic that of its interest. But, I am not sure = if the other direction is a common practice. As we all know: IETF is a publ= ic organization and anyone can access the information regarding any workgro= up charter free of charge. Any individual in the whole world can become a m= ember of any mailing list and participate in the discussion, etc... That is NOT the case in other SDOs. I believe if any SDO is interested in a= ny IETF topic should be able to follow the progress of that topic free of c= harge on the respected WG. If the information is NOT available on IETF webs= ite, then IETF probably is not working on it to start with. Just an idea: May be if 3GPP SA2 is NOT aware of IETF NetExt published char= ters, they could send an LS to officially inquire about the charter and any= specific item progress. What do you think?=20 Regards, Ahmad -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Wednesday, April 21, 2010 11:52 AM To: julienl@qualcomm.com; rkoodli@cisco.com; Ahmad Muhanna; netext@ietf.org Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP Julien, There is no harm in sending the LS. It is informative. While SA2 can just a= s well read the text of the Netext charter, we do have a channel to provide= such informative updates through liason statements and we are simply using= that.=20 -Raj On 4/21/10 9:49 AM, "ext Laganier, Julien" wrote: > Hi Rajeev, >=20 > I am still not sure why we are spontaneously sending an LS to 3GPP... >=20 > Rajeev Koodli wrote: >>=20 >> Hi Julien, Ahmad, >>=20 >> this LS is informative. It is making it known (officially from IETF=20 >> perspective, if you will) that the NetExt WG is working on Flow=20 >> Mobility for PMIP6. >>=20 >> We have heard some arguments in 3GPP that status of this work in IETF=20 >> is unclear. >=20 > Who is we in "we have heard ..."? >=20 > Also - how can the status of this work in the IETF be unclear when it=20 > is explicitly listed on the NETEXT WG charter? >=20 >> This is making it clear and official, that's all. >=20 > If 3GPP is wondering what is the official status of this work in IETF,=20 > why don't they read the NETEXT charter? >=20 > Best, >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Wed Apr 21 10:49:08 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC5A3A69E3 for ; Wed, 21 Apr 2010 10:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qID8JlcqUm9Q for ; Wed, 21 Apr 2010 10:49:07 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5E01228C197 for ; Wed, 21 Apr 2010 10:40:58 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3LHebHa030875; Wed, 21 Apr 2010 20:40:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 20:40:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 20:40:34 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 21 Apr 2010 19:40:34 +0200 From: To: , , , Date: Wed, 21 Apr 2010 19:40:30 +0200 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIwACuvCEYAAIMYQAABLckm Message-ID: In-Reply-To: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2010 17:40:34.0964 (UTC) FILETIME=[BF436D40:01CAE179] X-Nokia-AV: Clean Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:49:08 -0000 Hi Ahmad, On 4/21/10 12:16 PM, "ext Ahmad Muhanna" wrote= : > Hi Raj, >=20 > I think we are setting a precedence here. I am not aware of IETF sending > unsolicited LSes; but I could be wrong. Sending an LS and that too an informative one is not a big deal. And it not precedence setting. See for example: https://datatracker.ietf.org/liaison/878/ https://datatracker.ietf.org/documents/LIAISON/file977.txt >=20 > On the other hand, I understand other SDOs sending an LS to IETF requesti= ng > IETF to work on a specific topic that of its interest. But, I am not sure= if > the other direction is a common practice. As we all know: IETF is a publi= c > organization and anyone can access the information regarding any workgrou= p > charter free of charge. Any individual in the whole world can become a me= mber > of any mailing list and participate in the discussion, etc... Most SDOs are internally focused and I don't expect them to be scanning wha= t is happening in various WGs in the IETF. Making another SDO aware of some ongoing work that may be of interest does no harm. >=20 > That is NOT the case in other SDOs. I believe if any SDO is interested in= any > IETF topic should be able to follow the progress of that topic free of ch= arge > on the respected WG. If the information is NOT available on IETF website,= then > IETF probably is not working on it to start with. See above comment w.r.t SDO interest vs ability to follow and know what is going on in a WG. As you are well aware the work on flow mobility is a new addition to the Netext charter. >=20 > Just an idea: May be if 3GPP SA2 is NOT aware of IETF NetExt published > charters, they could send an LS to officially inquire about the charter a= nd > any specific item progress. What do you think? Why does the request have to come from SA2? And what harm do you see in the IETF sending an informative LS to 3GPP SA2? I fail to understand why there is a concern with sending such an LS. Anyway, I think we have heard at least a couple of opinions about sending this LS. Will let our AD decide on the action. -Raj >=20 > Regards, > Ahmad >=20 > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Wednesday, April 21, 2010 11:52 AM > To: julienl@qualcomm.com; rkoodli@cisco.com; Ahmad Muhanna; netext@ietf.o= rg > Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP >=20 >=20 > Julien, >=20 > There is no harm in sending the LS. It is informative. While SA2 can just= as > well read the text of the Netext charter, we do have a channel to provide= such > informative updates through liason statements and we are simply using tha= t. >=20 > -Raj >=20 >=20 > On 4/21/10 9:49 AM, "ext Laganier, Julien" wrote: >=20 >> Hi Rajeev, >>=20 >> I am still not sure why we are spontaneously sending an LS to 3GPP... >>=20 >> Rajeev Koodli wrote: >>>=20 >>> Hi Julien, Ahmad, >>>=20 >>> this LS is informative. It is making it known (officially from IETF >>> perspective, if you will) that the NetExt WG is working on Flow >>> Mobility for PMIP6. >>>=20 >>> We have heard some arguments in 3GPP that status of this work in IETF >>> is unclear. >>=20 >> Who is we in "we have heard ..."? >>=20 >> Also - how can the status of this work in the IETF be unclear when it >> is explicitly listed on the NETEXT WG charter? >>=20 >>> This is making it clear and official, that's all. >>=20 >> If 3GPP is wondering what is the official status of this work in IETF, >> why don't they read the NETEXT charter? >>=20 >> Best, >>=20 >> --julien >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 From rkoodli@cisco.com Wed Apr 21 11:02:39 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BEA628C0E9 for ; Wed, 21 Apr 2010 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.507 X-Spam-Level: X-Spam-Status: No, score=-9.507 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAgmTpt1trz2 for ; Wed, 21 Apr 2010 11:02:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 450443A6C99 for ; Wed, 21 Apr 2010 10:58:25 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA7ZzkutJV2Z/2dsb2JhbACcEnGjc5o9hQ8E X-IronPort-AV: E=Sophos;i="4.52,251,1270425600"; d="scan'208";a="103738802" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2010 17:58:15 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o3LHwExO028654; Wed, 21 Apr 2010 17:58:14 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Apr 2010 13:55:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 13:53:12 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609382D5B@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIwACuvCEYAAiKOPw== References: From: "Koodli, Rajeev" To: , , , X-OriginalArrivalTime: 21 Apr 2010 17:55:46.0857 (UTC) FILETIME=[DECB4190:01CAE17B] Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 18:02:39 -0000 Hi Julien, apparently, they (SA2) have not followed the discussions in NetExt = closely - I am not blaming them, I would not be able to follow either. So, the LS provides a means to inform officially. Do you have any comments about the content of the LS itself? Thanks, -Rajeev -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Wed 4/21/2010 9:52 AM To: julienl@qualcomm.com; Koodli, Rajeev; ahmad.muhanna@ericsson.com; = netext@ietf.org Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP =20 Julien, There is no harm in sending the LS. It is informative. While SA2 can = just as well read the text of the Netext charter, we do have a channel to = provide such informative updates through liason statements and we are simply = using that.=20 -Raj On 4/21/10 9:49 AM, "ext Laganier, Julien" wrote: > Hi Rajeev, >=20 > I am still not sure why we are spontaneously sending an LS to 3GPP... >=20 > Rajeev Koodli wrote: >>=20 >> Hi Julien, Ahmad, >>=20 >> this LS is informative. It is making it known (officially from IETF >> perspective, if you will) that the NetExt WG is working on Flow = Mobility >> for PMIP6. >>=20 >> We have heard some arguments in 3GPP that status of this work in >> IETF is unclear. >=20 > Who is we in "we have heard ..."? >=20 > Also - how can the status of this work in the IETF be unclear when it = is > explicitly listed on the NETEXT WG charter? >=20 >> This is making it clear and official, that's all. >=20 > If 3GPP is wondering what is the official status of this work in IETF, = why > don't they read the NETEXT charter? >=20 > Best, >=20 > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Wed Apr 21 11:08:20 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0B53A69D7 for ; Wed, 21 Apr 2010 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu8esJTuefgM for ; Wed, 21 Apr 2010 11:08:20 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5BCBC3A68F8 for ; Wed, 21 Apr 2010 11:04:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO/azkutJV2b/2dsb2JhbACcEnGjc5o/hQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,251,1270425600"; d="scan'208";a="103880162" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2010 18:04:41 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o3LI4e8K013064; Wed, 21 Apr 2010 18:04:40 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Apr 2010 14:02:12 -0400 Received: from 10.21.169.225 ([10.21.169.225]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Apr 2010 18:02:12 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 21 Apr 2010 11:06:32 -0700 From: Rajeev Koodli To: , , , Message-ID: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIwACuvCEYAAIMYQAABLckmAADowkw= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Apr 2010 18:02:12.0834 (UTC) FILETIME=[C4DAAC20:01CAE17C] Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 18:08:21 -0000 On 4/21/10 10:40 AM, "Basavaraj.Patil@nokia.com" wrote: >> >> On the other hand, I understand other SDOs sending an LS to IETF requesting >> IETF to work on a specific topic that of its interest. But, I am not sure if >> the other direction is a common practice. As we all know: IETF is a public >> organization and anyone can access the information regarding any workgroup >> charter free of charge. Any individual in the whole world can become a member >> of any mailing list and participate in the discussion, etc... > > Most SDOs are internally focused and I don't expect them to be scanning what > is happening in various WGs in the IETF. Making another SDO aware of some > ongoing work that may be of interest does no harm. > It is also in NetExt and SA2 interest to officially know about the work being done in NetExt. -Rajeev From ahmad.muhanna@ericsson.com Thu Apr 22 00:07:00 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A6C3A6403 for ; Thu, 22 Apr 2010 00:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q63pLv6O-DaN for ; Thu, 22 Apr 2010 00:06:58 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 976C83A688E for ; Thu, 22 Apr 2010 00:06:58 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3M76lEP001820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Apr 2010 02:06:47 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.178]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 22 Apr 2010 03:06:46 -0400 From: Ahmad Muhanna To: "Basavaraj.Patil@nokia.com" , "julienl@qualcomm.com" , "rkoodli@cisco.com" , "netext@ietf.org" Date: Thu, 22 Apr 2010 03:06:45 -0400 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIwACuvCEYAAIMYQAABLckmABpZjfA= Message-ID: <1FCAE7B6027FE3489B8497A060C704C4261B925FE2@EUSAACMS0714.eamcs.ericsson.se> References: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 07:07:00 -0000 Hello Raj, So far, we know the following: 1. Out of the blue, an email from the WG chair(s) proposes an informational= LS to 3GPP (SA2) without any explanation why and what causes this spontane= ous LS to be sent. 2. When I raised the issue why this was NOT addressed as part of the semi-r= egular IETF-3GPP meeting/CC, there was no answer and it was brushed away. 3. When you guys were questioned on who you refer to when you say "We", the= re was also another NetExt Chairs style of brushing the question. 4. And NOW, you are telling us that enough is enough, you and your co-chair= have heard enough of this and ready to make a decision. After all, why did you guys have to share this on the mailing list to start= with? May be all what you needed to do is just send the LS to 3GPP and no = need to include the WG in the discussion [you already TRUST/ACCEPT whoever = privately conveyed the information Biased or NOT, it does not seem to matte= r] and without you answering any of the questions which are as follows: 1. Why this issue was NOT addressed in the semi-regular IETF-3GPP meeting/C= C? 2. Who are the individuals that brought this issue to the attention of the = WG chairs? 3. Since there was NO official communication from 3GPP SA2 regarding this s= ubject (LS), what was the criteria the WG chair(s) followed on accepting pr= ivate personal opinions assuming as if they reflect the official concern of= 3GPP SA2. 4. If flow mobility is very important to the WG Chairs, why the WG Chairs d= id not send an LS to other SDOs to keep them informed? Some of these SDOs h= ave adopted PMIP6 as it was being developed. 5. Once again, if this issue is so critical and important to 3GPP SA2, why = those folks who have been active behind the seen to bring this LS to light = did NOT influence SA2 to request the information to start with? Finally, I am not against PMIP6 addressing flow mobility and advertising th= at to the whole world; [may be we can have a commercial about it:)] but I a= m against the way things is conducted in the WG from day ONE! May be it is = time for things to be addressed and discussed fairly and on the clear! It i= s obvious that both Chairs have favorable views for sending the LS BUT you = should NOT run the discussion in a biased way favoring your views. Cheers! Regards, Ahmad -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Wednesday, April 21, 2010 12:41 PM To: Ahmad Muhanna; julienl@qualcomm.com; rkoodli@cisco.com; netext@ietf.org Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP Hi Ahmad, On 4/21/10 12:16 PM, "ext Ahmad Muhanna" wrote= : > Hi Raj, >=20 > I think we are setting a precedence here. I am not aware of IETF=20 > sending unsolicited LSes; but I could be wrong. Sending an LS and that too an informative one is not a big deal. And it not= precedence setting. See for example: https://datatracker.ietf.org/liaison/878/ https://datatracker.ietf.org/documents/LIAISON/file977.txt >=20 > On the other hand, I understand other SDOs sending an LS to IETF=20 > requesting IETF to work on a specific topic that of its interest. But,=20 > I am not sure if the other direction is a common practice. As we all=20 > know: IETF is a public organization and anyone can access the=20 > information regarding any workgroup charter free of charge. Any=20 > individual in the whole world can become a member of any mailing list and= participate in the discussion, etc... Most SDOs are internally focused and I don't expect them to be scanning wha= t is happening in various WGs in the IETF. Making another SDO aware of some= ongoing work that may be of interest does no harm. >=20 > That is NOT the case in other SDOs. I believe if any SDO is interested=20 > in any IETF topic should be able to follow the progress of that topic=20 > free of charge on the respected WG. If the information is NOT=20 > available on IETF website, then IETF probably is not working on it to sta= rt with. See above comment w.r.t SDO interest vs ability to follow and know what is = going on in a WG. As you are well aware the work on flow mobility is a new = addition to the Netext charter. >=20 > Just an idea: May be if 3GPP SA2 is NOT aware of IETF NetExt published=20 > charters, they could send an LS to officially inquire about the=20 > charter and any specific item progress. What do you think? Why does the request have to come from SA2? And what harm do you see in the= IETF sending an informative LS to 3GPP SA2? I fail to understand why there= is a concern with sending such an LS. Anyway, I think we have heard at least a couple of opinions about sending t= his LS. Will let our AD decide on the action. -Raj >=20 > Regards, > Ahmad >=20 > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Wednesday, April 21, 2010 11:52 AM > To: julienl@qualcomm.com; rkoodli@cisco.com; Ahmad Muhanna;=20 > netext@ietf.org > Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP >=20 >=20 > Julien, >=20 > There is no harm in sending the LS. It is informative. While SA2 can=20 > just as well read the text of the Netext charter, we do have a channel=20 > to provide such informative updates through liason statements and we are = simply using that. >=20 > -Raj >=20 >=20 > On 4/21/10 9:49 AM, "ext Laganier, Julien" wrote: >=20 >> Hi Rajeev, >>=20 >> I am still not sure why we are spontaneously sending an LS to 3GPP... >>=20 >> Rajeev Koodli wrote: >>>=20 >>> Hi Julien, Ahmad, >>>=20 >>> this LS is informative. It is making it known (officially from IETF=20 >>> perspective, if you will) that the NetExt WG is working on Flow=20 >>> Mobility for PMIP6. >>>=20 >>> We have heard some arguments in 3GPP that status of this work in=20 >>> IETF is unclear. >>=20 >> Who is we in "we have heard ..."? >>=20 >> Also - how can the status of this work in the IETF be unclear when it=20 >> is explicitly listed on the NETEXT WG charter? >>=20 >>> This is making it clear and official, that's all. >>=20 >> If 3GPP is wondering what is the official status of this work in=20 >> IETF, why don't they read the NETEXT charter? >>=20 >> Best, >>=20 >> --julien >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 From Basavaraj.Patil@nokia.com Thu Apr 22 12:53:15 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F72D28C112 for ; Thu, 22 Apr 2010 12:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR7sBO9W-e+d for ; Thu, 22 Apr 2010 12:53:14 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id F2CBE3A68B3 for ; Thu, 22 Apr 2010 12:48:16 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3MJlhfs022605 for ; Thu, 22 Apr 2010 22:48:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 22:47:12 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 22:47:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 22:46:59 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 22 Apr 2010 21:46:58 +0200 From: To: Date: Thu, 22 Apr 2010 21:46:56 +0200 Thread-Topic: Consensus call for adopting draft-xia-netext-radius-00 as WG document Thread-Index: AcriVJBTgl8pLxP7zUyjkmgyPr/2xA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2010 19:46:59.0988 (UTC) FILETIME=[92B3FD40:01CAE254] X-Nokia-AV: Clean Subject: [netext] Consensus call for adopting draft-xia-netext-radius-00 as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:53:15 -0000 Hello, At IETF77 we had consensus on adopting I-D: draft-xia-netext-radius-00 as a WG document.=20 This is a followup on the ML w.r.t the consensus reached at IETF77. If you have any concerns or objections to adopting this I-D as a Netext WG document, please speak up (on the list or send a note to the chairs). -Chairs From julienl@qualcomm.com Thu Apr 22 12:57:37 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DF13A688C for ; Thu, 22 Apr 2010 12:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7iDajY8TRWx for ; Thu, 22 Apr 2010 12:57:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8C0B63A6A5E for ; Thu, 22 Apr 2010 12:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1271966131; x=1303502131; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Koodli,=20Rajeev"=20,=20"Basav araj.Patil@nokia.com"=0D=0A=09 ,=20"ahmad.muhanna@ericsson.com"=0D=0A=09,=20"netext@ietf.org"=20 |Date:=20Thu,=2022=20Apr=202010=2012:55:27=20-0700 |Subject:=20RE:=20[netext]=20Liaison=20Statement=20on=20F low=20Mobility=20to=203GPP|Thread-Topic:=20[netext]=20Lia ison=20Statement=20on=20Flow=20Mobility=20to=203GPP |Thread-Index:=20Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGh aOAAC1G2iQAALqIwACuvCEYAAiKOPwA1saFA|Message-ID:=20|References:=20=0D=0A=20<4D35478224365146822AE9E3AD4A266609382D5 B@exchtewks3.starentnetworks.com>|In-Reply-To:=20<4D35478 224365146822AE9E3AD4A266609382D5B@exchtewks3.starentnetwo rks.com>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=rEbHmctzwlgcCHh3ELGFATg93AMO162rJUsjvhj6mws=; b=yvwfEK/ZNzf8kMqHZFeOmofsrBJTGMn9h1Rkh0THSpK7mpZkAQ8fTL5V DXY6Rz8cqUCMW98n5G+RNi4FyBSSyhiWEQ3JwNqV99yTLEf3xUtrsKbPm ERMC/CA23YJAs3aoTJQjVjnB1jGzBj9I8wlyQnhSoH7iwu5wy/ylHFS/K 0=; X-IronPort-AV: E=McAfee;i="5400,1158,5960"; a="39390635" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine02.qualcomm.com with ESMTP; 22 Apr 2010 12:55:31 -0700 X-IronPort-AV: E=Sophos;i="4.52,258,1270450800"; d="scan'208";a="22624684" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 22 Apr 2010 12:55:31 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 22 Apr 2010 12:55:31 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 22 Apr 2010 12:55:31 -0700 From: "Laganier, Julien" To: "Koodli, Rajeev" , "Basavaraj.Patil@nokia.com" , "ahmad.muhanna@ericsson.com" , "netext@ietf.org" Date: Thu, 22 Apr 2010 12:55:27 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AAmML6AAAGhaOAAC1G2iQAALqIwACuvCEYAAiKOPwA1saFA Message-ID: References: <4D35478224365146822AE9E3AD4A266609382D5B@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382D5B@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:57:37 -0000 Rajeev & Raj, Koodli, Rajeev wrote: >=20 > apparently, they (SA2) have not followed the discussions in NetExt > closely - I am not blaming them, I would not be able to follow either. > > So, the LS provides a means to inform officially. I am unsure about whether or not the SA2 WG and/or its participants _appear= _ to follow closely or not NETEXT -- or any other specific topic, for that = matter.=20 I am however sure that SA2 is _factually_ aware that the NETEXT WG is worki= ng on flow mobility _because_ they have discussed a contribution (from Cisc= o BTW) that highlighted the fact that the NETEXT WG had been rechartered to= work on flow mobility: It is also _factually_ official that the NETEXT WG is working on flow mobil= ity _because_ it is stated on the NETEXT charter.=20 > Do you have any comments about the content of the LS itself? Let's not put the cart before the horses. We can discuss the content of the= LS once we have determined whether there is a need to send an LS in the fi= rst place. Best, --julien From Basavaraj.Patil@nokia.com Thu Apr 22 13:34:56 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED573A6359 for ; Thu, 22 Apr 2010 13:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.788 X-Spam-Level: X-Spam-Status: No, score=-4.788 tagged_above=-999 required=5 tests=[AWL=-1.389, BAYES_50=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEJoG3vob4+m for ; Thu, 22 Apr 2010 13:34:54 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 244263A68DF for ; Thu, 22 Apr 2010 13:34:51 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3MKYUJl005378 for ; Thu, 22 Apr 2010 23:34:39 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 23:33:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 23:32:58 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 22 Apr 2010 22:32:57 +0200 From: To: Date: Thu, 22 Apr 2010 22:32:55 +0200 Thread-Topic: Draft minutes of WG meeting minutes from IETF77 Thread-Index: AcriWvzR+NBHkWaYS0e4Xz9cYrtJpw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2010 20:32:58.0346 (UTC) FILETIME=[FED004A0:01CAE25A] X-Nokia-AV: Clean Subject: [netext] Draft minutes of WG meeting minutes from IETF77 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 20:34:56 -0000 Please review the minutes and let the chairs know if any change is needed. -Basavaraj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Network-Based Mobility Extensions (netext) WG meeting minutes from IETF77 Date: March 25, 2010 (1300-1500) Chairs: Basavaraj Patil (basavaraj.patil@nokia.com) Rajeev Koodli (rkoodli@cisco.com) Minutes by: Ryuji Wakikawa Jabber scribe: Behcet Sarikaya Thanks to Ryuji and Behcet for volunteering. Audio archive: ftp://videolab.uoregon.edu/pub/videolab/media/ietf77/ietf77-ch8-thur-afnoon= . mp3 Jabber archive: http://www.ietf.org/jabber/logs/netext/2010-03-25.txt ----------------------------------------------------- - Agenda Bashing - WG Status o Charter approved with work items that include flow mobility, inter-technology handovers and radius extensions for PMIP6 o Bulk re-reg I-D published as WG doc o Localized routing PS I-D is fairly stable and we may go to WG LC soon. Scope of PS I-D includes scenarios which may be greater than what the solution I-D will tackle. --------------------------------------- 1. LMA runtime selection (Jouni Korhonen) I-D: draft-ietf-netext-redirect-01 Raj (Chair hat): In order to go for WGLC, we need more reviews from WG Please review this doc and feedback to authors. Chairs also request some volunteer for review. After further improvements to this document, following reviews we will take it to WGLC. Suresh Krishnan, Jonne Soininen and, Qin Wu volunteer for the review during the meeting. Raj requests Mohana Jeyatharan to review the I-D. --------------------------------------- 2. Bulk Re-registration for PMIP6 (Fuad Abinader) I-D: draft-ietf-netext-bulk-re-registration-00 Raj (chair hat): For the bitmap proposal, we should analyze the scenario an= d applicability first. We should take that discussion on the list and see how we can optimize the bulk registration. As discussed for the previous document, this one also needs review to improve the document. Chairs create tracker for this document. --------------------------------------- 3. Radius support for PMIP (Frank Xia) I-D: draft-xia-netext-radius-00 Chairs: This was a NETLMM chartered item. Chairs of NETLMM/NETEXT and relevant AD (Jari) discussed it and decided to take this item in NETEXT. Raj: We agreed on taking this doc to NETEXT. Any objection to use this document as a baseline? Alper: Have you looked at WiMAX attribute? Frank: Yes, Damjan is co-author and inputs the WiMAX parts to this document= . Chairs: consensus call Any objection to use this as a baseline? Clearly no objection. Raj: WG will take the doc as a WG document after following up on the ML. --------------------------------------- 4. PMIP6 Local Routing (Suresh Krishnan) I-D: draft-krishnan-netext-pmip-lr-01 How many people have read the problem statement doc? About 10-15 in the room Suresh: Authors have not reached consensus on the A12 scenario. Sri: In A21, what is the optimized routing path here? Suresh: The optimized path is bypassing the tunnel. Sri: For the inter-domain optimization, it requires security relationships between domains. Suresh: right Frank: All solutions assume communication between mobile nodes. Any consideration of fixed nodes? Suresh: It's all connecting to the PMIP domain, all the communication go to LMA. Rajeev: If LMA does not have a binding (i.e. for fixed nodes), it's impossible to run LR. Kent: About scenario A11, Any indication to know whether MAG supports LR. Suresh: there is mechanism to tell "cannot do it", "don't want to do it". Kent: At least, there is a mechanism to support the indicator of LR. Rajeev; other choice is configuration. Suresh: You don't need to know which MAG support LR. There is a flag in the signaling. Jari: This design choice is right one. The minimum amount of info to configure on LMA/MAG. It supports the scenarios of mixing MAGs supporting LR or regular MAG. There is no need to negotiate LR dynamically. Kent: Clarification. When a mobile moves away from MAG, is LR implicitly or explicitly tore down? Suresh: update or tore down. Kent: In A11, LMA can explicitly team down LR to MAG1. Suresh: Yes, explicit tear down from LMA. Suresh: rough consensus not to support A22 scenario among authors. Everything we've discussed in PS does not need to be supported in the solution. More importantly we should quickly finish this work. Now it's open questions to the room. Sri: The PMIP protocol assumes clear security assumption between LMA and MAG. Putting A22 in Appendix. Suresh: We don't have any solution. Scenario is captured in the PS draft. So no need to discuss it in this doc. Marco (via jabber): In A12, what happens if MN2 hands over to a different MAG? The protocol runs into an out of scope situation. How do we handle this? Suresh: Drop LR session. we don't know how to solve A22. No support this scenario. drop LR session and go back to the regular one. Yuri: Handover between two LMAs. Prefix allocated to MN will be changed. i.e. Inter-LMA handover. Suresh: we don't go that scenario. no support. However, in A12, we have discussed inter-MAG handover. Yuri: A22 should not include in the solution. This leads complications to the solution. Bechet: why? Marco: taking out A22 is unclear. What is technical issue. Suresh: We can do something else. DIME has to support it. Security relation, when MAG1 and MAG2 in the different domain, how we can establish security relationship for the inter-domain. Consensus call Raj: A22 is relevant to this document? five people. (including jabber) not relevant 10 people Suresh: what are the chairs calling here? Rajeev: We should handle what we know well with 5213 as the basis. Rajeev: Chairs are open to have another document later when there is enough understanding of this case. Raj: Do we need MAG1-MAG2 dynamic tunnel establishment. Should we also specify how to establish tunnels between MAGs. This is open question. at least we should discuss it. Suresh: why is it in the scope? Rajeev: Two distinct function for LR: initiation and termination of LR, handling HO. Qin Wu: We should setup a tunnel between MAGs dynamically. Suresh: do you think we need this LR dynamic support? Or can we assume the tunnel is there?Do you support dynamic path setup or not? Raj: LR can use pre-established or configured tunnels between MAGs. It's straight forward. However this is just one way. Other option is to introduce a new protocol to establish a tunnel dynamically with signaling as an ALTERNATIVE solution. what does WG consider this? Suresh: as an editor, no need to have dynamic tunnel. Qin Wu: scalability is issue. Suresh: what is the benefit. Qin: you just need to define two messages Kent: The statically configured tunnel is just a PIPE. In addition to that, you need something forwarding setup to route the packets to the pipe. signaling for forwarding is required? Suresh: Yes, but it is more a local matter. No message exchange is required. Kent: we still need some external message to route the packets to the right tunnels Suresh: No. Kent: How to pick up which tunnel should be used for LR? Suresh: there is a message from LMA. Kent: Do you say LR is initiated from LMA only when LMA verifies both MAGs agree on LR? Otherwise, it should not initiate LR Kent: more window of failure. Suresh: agree with you. We still need some mechanism to fall back from LR. Rajeev: packets loss is an issue. we do LR for optimized performance. we have a protocol for inter-MAG handover. we should have reference for it. FPMIP. how does source MAG know the destination MAG. You need a routing entry for LR. Suresh: We don't need any message for it. MAG has local database for tunnel= . Suresh: Kent requires 3 way hand-shake (both MAG accepted LR, then going to LR), confirm both MAGs and initiates LR. Rajeev: point is "if MAG has one entry it starts forwarding, MAG2 does not have setting yet?" Suresh: half-open state is open problem. Rajeev: talk details offline Kent: Don't state this half-open state issue. Raj: open the tracker for this problem. discuss on the list. Sri: we need consideration section to clarify so many features. Rajeev: Specify default, and if needed choose one of optional features and just configure it. Raj: We will adapt this as a WG doc. ----------------------- Rajeev: new topics after rechartering: 1. logical interface 2. enable flow mobility and 3. inter-tech handover. No host protocol changes is one requirement. ----------------------- 5. Applicability Statement on Logical Interface over Multiple Physical Interfaces (Telemaco Melia) I-D: draft-bernardos-netext-ll-statement-01 Frank: Is it logical or virtual IF? Rajeev: we use the term "logical interface" in the charter. Sri: another presentation from Hidetoshi Yokota has clear discussion of relationship between phy if and virtual IF. This presentation just gives the higher view of this logical interface. Yuri: conceptual question. Is this the case when PMIP is connected. Telmaco: Yes Kent: PMIP6 domain, two different access networks. assumption is assignment of the same prefix. Are Prefix1 and Prefix2 the same prefix during the handover? Sri: This does not deal with the handover scenario, but the MN attached to multiple access networks of the same domain. Julien: The draft is not well fit to what the charter specified. For example, This document doesn't discuss the MTU, no consideration of NDP and Neighbor reachability detection, etc. The desired document should give us recommendation or statement of possible issues per scenarios. Rajeev: We can not violate 4831 in any of the possible solutions Jari: The original idea of this document was to cover the general things. It should talk about the expectation and type of models, requirement. What we should consider for Default router selection, MTU, etc. These discussion must be included in this document. Raj: MN uses only a logical interface when it is multihomed? When a MN is attached with a single PHY interface, it is still using the logical interface? Sri: Yes. Raj: We should have Applicability statement of the logical interface. (flow mobility, inter-tech HO) Jari: I am confused with this picture. Ideally hiding the multihomed phy IF from IP stack, but it exposes multiple prefixes to the IP stack in the picture. Expecting some signaling in L2, hiding phy details from IP. From the IP perspective, it always uses the same default router etc. Is it the case of this picture? Telmaco: yes. Raj: it is basically hiding physical interfaces. It does not mean hiding the prefix. Jari: no flow mobility unless you have multiple prefixes. I am against it. You can still distribute multiple flows without multiple prefixes. Rajeev: Right. Same prefix and split the traffic to multiple phy interface. Sri: this is solution space. Raj: this figure is not the right one to explain the logical interface. one prefix to logical interface. During handover, prefix remains the same Julien: The slide picture is confusing. Raj: obviously more work need to be done for this document. I recommend authors to take these inputs from Julien/Jari to the document and explain it further. Sri: About the structure of this document, it should not get into the solution. high level guideline only. Kent: It needs to consider the ingress filtering Yuri: expecting many solutions for this? Why do we need two documents? Isn't it enough to have a document for the logical interface? Rajeev: this document just analyze what is the concept and what need for flow mobility work. As a result, it may turn out to be one document. Julien: We don't have a charter to hide prefixes by logical interface. Jari: You are chartered to do explaining general approach and another charter to work parts for PMIP6, but not charter for middle part (how to make logical interface work). The first document must be overall document. It should explain the whole picture.This document is pretty far from the expectation. Sri: many protocols are introduced between MAG and LMA, this is the host side solution. ----------------------- 6. Inter-tech HO with PMIP (Hidetoshi Yokota) I-D: draft-yokota-netlmm-pmipv6-mn-itho-support-03 Yuri: Application only sees the virtual interface and multiple prefixes. Which address shall application pick up? Sri: Up to source address selection. Yokota: This document does not discuss which address should be picked. Dapeng: between L2.5-L3. You should have a control for routing table. You need some program interface to the IP layer. Yokota: 2.9? Virtual interface needs to access IP layer somehow. Dapeng you need to change the application? Yokota: no, it's about device driver, bonding driver ?? (ETRI): No modifications from the application layer Julien: Charter review again. This is all about the implementation detail, MAC ID are out of scope in this group. We don't need to discuss this here. Rajeev: Charter said logical interface for flow mobility. we need to know how it works. anyway, we need to figure out what documents WG should deliver? We need some documentation. Jari; For flow mobility support, what is the host expectation, limitation, assumption. From my quick view of presentation/document, it only discusses implementation. It is missing the conceptual part of this issue. It's only describing the end of idea. Implication of what? what is the capability of L2? One example is, in 3GPP, with multiple physical interfaces, link-layer aware of these multiple access networks and host only see one interface. No charter to develop a new link layer. describing existing link-layer, and deal with more general issues in the charter. Rajeev: I don't know we have experts to describe GPRS work. Jari: No, just explaining the assumption for this logical interface. assumption to the IP stack? This documents is only discussed one solution, We need more focus on implication and explanation of whole things. Jari: This is relatively easily to do. It should be short document. Julien: agree with Jari. We don't need to describe the 3GPP work. When hiding movement from wifi to 3G, what shall we expose to IP? Sri: If we don't explain the detail in the document, how can we define the protocol for the further PMIP extension? Jari: we need some level of details, you miss the generic implication to the implementation. Young (ETRI): virtual interface can be easily implemented on linux. virtual interafce is generic to handle multihoming. Using virtual interface for flow mobility, we need more general concept. -------------- 7. Flow mobility for PMIP6 Raj: Scope of flow mobility: a node does not involve in any signaling to direct the flows. Some of the approaches utilize some info from L2 to signa= l MAG to direct the flows to specific interfaces. We should not look at how the MN is doing signaling to control the flows. Rajeev: The base protocol should look at the LMA and MAG signaling even if there is L2 signaling from MN to MAG. From gwz@net-zen.net Thu Apr 22 20:00:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902673A685A for ; Thu, 22 Apr 2010 20:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+C4NTcrXbw6 for ; Thu, 22 Apr 2010 20:00:35 -0700 (PDT) Received: from p3plsmtpa01-08.prod.phx3.secureserver.net (p3plsmtpa01-08.prod.phx3.secureserver.net [72.167.82.88]) by core3.amsl.com (Postfix) with SMTP id A40F73A67B4 for ; Thu, 22 Apr 2010 20:00:35 -0700 (PDT) Received: (qmail 24812 invoked from network); 23 Apr 2010 03:00:24 -0000 Received: from unknown (115.67.32.233) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 23 Apr 2010 03:00:21 -0000 From: "Glen Zorn" To: References: In-Reply-To: Date: Fri, 23 Apr 2010 10:00:08 +0700 Organization: Network Zen Message-ID: <000001cae291$1b8b9bf0$52a2d3d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcriVJBTgl8pLxP7zUyjkmgyPr/2xAAOZkBA Content-Language: en-us Cc: netext-chairs@tools.ietf.org Subject: Re: [netext] Consensus call for adopting draft-xia-netext-radius-00 as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 03:00:36 -0000 Basavaraj Patil [mailto://Basavaraj.Patil@nokia.com] writes: > Hello, > > At IETF77 we had consensus on adopting I-D: draft-xia-netext-radius-00 > as a > WG document. > > This is a followup on the ML w.r.t the consensus reached at IETF77. > > If you have any concerns or objections to adopting this I-D as a Netext > WG > document, please speak up (on the list or send a note to the chairs). I have no objections to the adoption of the draft but a quick review of the document does raise a few issues. There are a few references to Diameter that seem irrelevant and lots of grammatical errors, but the most obvious question is of the consistent duplication of attributes. For example, why are both PMIP6-Home-LMA-IPv6-Address & PMIP6-Visited-LMA-IPv6-Address defined? Are both attributes expected to occur the same RADIUS message? If so, this should be stated; if not then there is no need, AFAICT, for two attributes to be defined. The IANA Considerations section doesn't say whether the attribute numbers are to be assigned from the standard attribute namespace but I assume that they are; that space is small & rapidly being depleted, so I think that the unnecessary creation of standard RADIUS attributes should be avoided. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From xiayangsong@huawei.com Fri Apr 23 07:39:39 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7673A6946 for ; Fri, 23 Apr 2010 07:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o0CuC5tXIuf for ; Fri, 23 Apr 2010 07:39:38 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A21873A690D for ; Fri, 23 Apr 2010 07:39:38 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1C001ZF3DD2H@szxga01-in.huawei.com> for netext@ietf.org; Fri, 23 Apr 2010 22:39:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1C00BP63DDHC@szxga01-in.huawei.com> for netext@ietf.org; Fri, 23 Apr 2010 22:39:13 +0800 (CST) Received: from X24512z ([10.124.12.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1C00BM03DBBW@szxml06-in.huawei.com> for netext@ietf.org; Fri, 23 Apr 2010 22:39:13 +0800 (CST) Date: Fri, 23 Apr 2010 09:39:10 -0500 From: Frank Xia In-reply-to: <000001cae291$1b8b9bf0$52a2d3d0$@net> To: 'Glen Zorn' , netext@ietf.org Message-id: <003201cae2f2$be23ca20$510c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcriVJBTgl8pLxP7zUyjkmgyPr/2xAAOZkBAABiqgbA= References: <000001cae291$1b8b9bf0$52a2d3d0$@net> Cc: netext-chairs@tools.ietf.org Subject: Re: [netext] Consensus call for adopting draft-xia-netext-radius-00 as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 14:39:40 -0000 Hi Glen Thank for your insightful review as an AAA expert! Please check my inline reply. BR Frank -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Thursday, April 22, 2010 10:00 PM To: netext@ietf.org Cc: netext-chairs@tools.ietf.org Subject: Re: [netext] Consensus call for adopting draft-xia-netext-radius-00 as WG document Basavaraj Patil [mailto://Basavaraj.Patil@nokia.com] writes: > Hello, > > At IETF77 we had consensus on adopting I-D: draft-xia-netext-radius-00 > as a > WG document. > > This is a followup on the ML w.r.t the consensus reached at IETF77. > > If you have any concerns or objections to adopting this I-D as a Netext > WG > document, please speak up (on the list or send a note to the chairs). I have no objections to the adoption of the draft but a quick review of the document does raise a few issues. There are a few references to Diameter that seem irrelevant and lots of grammatical errors, Frank=>We will have a thorough self-check before submitting the draft. but the most obvious question is of the consistent duplication of attributes. For example, why are both PMIP6-Home-LMA-IPv6-Address & PMIP6-Visited-LMA-IPv6-Address defined? Are both attributes expected to occur the same RADIUS message? Frank=>Yes. When a mobile node moves into a visited network, it has choice to anchor home LMA or visited LMA based on its profile and carrier's policy. If so, this should be stated; Frank=>We will. if not then there is no need, AFAICT, for two attributes to be defined. The IANA Considerations section doesn't say whether the attribute numbers are to be assigned from the standard attribute namespace but I assume that they are; Frank=>You are right. that space is small & rapidly being depleted, so I think that the unnecessary creation of standard RADIUS attributes should be avoided. Frank=>Your concerns make sense. However, we think it is necessary to have two attributes as WiMAX does. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From jari.arkko@piuha.net Mon Apr 26 11:13:48 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A783A699C for ; Mon, 26 Apr 2010 11:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qegxYlQ8NhlO for ; Mon, 26 Apr 2010 11:13:47 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2E9B93A68AE for ; Mon, 26 Apr 2010 11:13:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D06A62CEB5; Mon, 26 Apr 2010 21:13:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPdf2vUq+BxZ; Mon, 26 Apr 2010 21:13:33 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 22FCA2CCC0; Mon, 26 Apr 2010 21:13:33 +0300 (EEST) Message-ID: <4BD5D7CC.3010603@piuha.net> Date: Mon, 26 Apr 2010 21:13:32 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ahmad Muhanna References: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:13:48 -0000 Ahmad, > I think we are setting a precedence here. I am not aware of IETF sending unsolicited LSes; but I could be wrong. > We do send many unsolicited liaison statements. For instance, when we wish to inform someone officially that something is happening, when we are worried about some development in some other SDO wrt IETF conflicts, etc. (The only question is whether we are providing interesting information in this case. Basavaraj and Rajeev have told me that there is some unclarity about NETEXT's mission. I have not observed that myself, but I also do not have an issue in informing 3GPP of ongoing work.) 3GPP - IETF management teleconferences are another way to send messages, but they do not necessarily always have the right people in the call. E.g., SA2 chairs do not participate them IIRC. In any case, the regular teleconferences are typically held maybe a month before the IETF, so there's probably some time still for the next one. The preferred method of informing other SDOs of ongoing work is joint participation, of course. We can supplement that with liaison statements and other tools where needed. Jari From ahmad.muhanna@ericsson.com Mon Apr 26 15:11:47 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA943A6BD9 for ; Mon, 26 Apr 2010 15:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX3ipW2ozMfP for ; Mon, 26 Apr 2010 15:11:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 720DF3A6BD7 for ; Mon, 26 Apr 2010 15:11:38 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3QMBMOj026719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Apr 2010 17:11:23 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.162]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 26 Apr 2010 18:11:22 -0400 From: Ahmad Muhanna To: Jari Arkko Date: Mon, 26 Apr 2010 18:11:19 -0400 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrlbEtGOGj8vYASSNa83DHvRqJTJgAHzNow Message-ID: <1FCAE7B6027FE3489B8497A060C704C4261CC65444@EUSAACMS0714.eamcs.ericsson.se> References: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> <4BD5D7CC.3010603@piuha.net> In-Reply-To: <4BD5D7CC.3010603@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 22:11:47 -0000 Jari, Thanks for the clarification. Makes sense. Please see one comment inline. Regards, Ahmad > -----Original Message----- > Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP >=20 > Ahmad, >=20 > > I think we are setting a precedence here. I am not aware of=20 > IETF sending unsolicited LSes; but I could be wrong. > > =20 >=20 > We do send many unsolicited liaison statements. For instance,=20 > when we wish to inform someone officially that something is=20 > happening, when we are worried about some development in some=20 > other SDO wrt IETF conflicts, etc. >=20 > (The only question is whether we are providing interesting=20 > information in this case. Basavaraj and Rajeev have told me=20 > that there is some unclarity about NETEXT's mission. I have=20 > not observed that myself, but I also do not have an issue in=20 > informing 3GPP of ongoing work.) [Ahmad] It would have been more meaningful and much appreciated if the chairs based= their views/feedback on the wg consensus rather than their own perception.= At minimum, following this thread, I too have a hard time believe that the= re is unclarity about Netext's mission with respect to flow mobility at 3GP= P SA2. Regards, Ahmad >=20 > 3GPP - IETF management teleconferences are another way to=20 > send messages, but they do not necessarily always have the=20 > right people in the call.=20 > E.g., SA2 chairs do not participate them IIRC. In any case,=20 > the regular teleconferences are typically held maybe a month=20 > before the IETF, so there's probably some time still for the next one. >=20 > The preferred method of informing other SDOs of ongoing work=20 > is joint participation, of course. We can supplement that=20 > with liaison statements and other tools where needed. >=20 > Jari >=20 > = From jouni.nospam@gmail.com Tue Apr 27 02:20:51 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8818E3A69FF for ; Tue, 27 Apr 2010 02:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.82 X-Spam-Level: * X-Spam-Status: No, score=1.82 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeTHFLJxCBNn for ; Tue, 27 Apr 2010 02:20:48 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 013683A6972 for ; Tue, 27 Apr 2010 02:20:29 -0700 (PDT) Received: by wyb35 with SMTP id 35so3458920wyb.31 for ; Tue, 27 Apr 2010 02:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CHGI/UqPrlC3QazBu+KJzs+TzF4dbCs2cy46A0suiFc=; b=tnmbD+p+3OsJVsvTiwbQ2DgezXe/maD/V5/qCYBd47tF6eKsWU0baq8gG7DKndG1B9 ZvajTWjuFjYSBdBqCjZHJcNk3DhEWxAG3mhh8YcB96qoulgaoDfI29DGe+JLNV5WeC3k 73zTR6k3O1kE+ugJNIo3EszgrW2e71stMI3I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=C1Kg/ziJY+0eX56JL90IhrMtXsoLdSpx7hWn1V67hRijv6p+jKGM4I06vSZhB9CDvM b/1c4PLFA+roWkPLeHtRjowrUKMLRRcQTq70akusaZU/8aukNGXxe+tdx7NBLlS+8Fwj RCArET0+3ztwLWzQYK+crcGqE3NS5wgoeQoj4= Received: by 10.216.158.3 with SMTP id p3mr1785894wek.9.1272360013929; Tue, 27 Apr 2010 02:20:13 -0700 (PDT) Received: from [10.254.0.253] ([192.100.123.77]) by mx.google.com with ESMTPS id z3sm3887105wbs.10.2010.04.27.02.20.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 02:20:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen X-Priority: 3 In-Reply-To: <003901cae142$42e893b0$23548a0a@china.huawei.com> Date: Tue, 27 Apr 2010 12:20:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0B943614-A501-4A6B-B448-12BCA7CB7B88@gmail.com> References: <002801cadc46$369ef910$23548a0a@china.huawei.com> <70F558D1-3955-4B70-9EB0-AC68A92D862D@gmail.com> <01d301cae030$ae6b2570$23548a0a@china.huawei.com> <4DC9B09C-C3D9-4208-BF47-74816A39CCCF@gmail.com> <003901cae142$42e893b0$23548a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 09:20:51 -0000 Hi Qin, On Apr 21, 2010, at 2:03 PM, Qin Wu wrote: [snip] >>=20 >>> Hi, >>> In Anaheim I volunteered to review this I-D. I think this I-D has = been in good shape. Here is my review of redirection document. >>> = --------------------------------------------------------------------------= ------------------------------------------------------- >>> In the section 1: >>> o LMAs with multiple IP addresses: a cluster of LMAs or a blade >>> architecture LMA may appear to the routing system as multiple = LMAs >>> with separate unicast IP addresses. A MAG can initially select >>> any of those LMA IP addresses as the LMA Address using e.g., = DNS- >>> and AAA-based solutions. However, MAG's initial selection may = be >>> suboptimal from the LMA point of view and immediate redirection = to >>> a "proper LMA" would be needed. The LMA could use [RFC5142] = based >>> approach but that would imply unnecessary setting up of a = mobility >>> session in a "wrong LMA" with associated backend support system >>> interactions, involve additional signaling between the MAG and = the >>> LMA, and re-establishing mobility session to the new LMA again >>> with associated signaling. >>>=20 >>> [Qin]: As described in [RFC5142], it seems changing the home = agent=20 >>> of mobile node is mainly becos load balance consideration or = overloaded >>> factor. Therefore not sure whether the bullet one(LMAs with = multiple IP >>> address) overlaps with bulltet two(Bypassing a load balancer). >>=20 >> These are two different cases. Bullet one is about a wrong LMA = selection decision made by a MAG that needs to be "corrected" by a LMA.. = using excess signaling and unnecessary intermediate, yet complete, state = creation in a LMA. Bullet two is about how to avoid a load balancing = entity becoming a bottleneck. >>=20 >> [Qin]: Okay, Would you like to clarify in which scenario will the = wrong LMA selection happen? >> a) In the exception case >> In this case, why will MAG choose the wrong LMA? >=20 > Typical example: load sharing based on DNS round-robin. LMA has no = proper way to feed up to date load information to global/local DNS so = that it would actually have any relevance (say.. caching times are too = long) or some vendor MAGs cache DNS responses outside the stub resolver. = Now it is rather likely that the LMA selected selected by the MAG is not = the most optimal seen by the "cluster" of LMAs. >=20 > [Qin]: Thank for your clarification. That is to say, If MAG choose the = out of date LMA using DNS based LMA discovery, it may result in = sub-optimal LMA selection. This sub-optimal LMA can be looked as "wrong = LMA". Right? Yes. >=20 >> b) load balance case >> In this case, the candiate LMA to which the MAG is going to register = intend to offload to the other backup LMAs. Do you think this candidate = LMA can be looked as >> wrong LMA? >> c) or overloaded situation >> In this case, the candiate LMA to which the MAG is going to register = is overloaded and need to transfer the load out.Do you think this = candidate LMA can be looked as >> wrong LMA? >=20 > I am slightly confused by the "candidate LMA" as I don't fully = understand what it means in this context. >=20 > [Qin]: I just try to figure out how to understand "wrong LMA" and what = cause wrong LMA selection. > I think if DNS based LMA discovery only provides sub-optimal LMA or = out of date LMA, we can use Redirection > mechanism described in the draft-ietf-netext-redirect to re-choose the = best choice or optimal LMA for the MAG. > But when MAG obtain one new LMA using DNS based approach, I believe = the MAG didn't know if this LMA obtained using DNS is optimal LMA or = wrong LMA. > Only when MAG register to this new LMA by sending PBU, this new LMA = can tell the MAG whether the LMA chosed by MAG is the optimal LMA.=20 > So what is the criterial to judge whether the LMA is wrong LMA or = optimal LMA? I think the only criteria is look at whether the new LMA is = overloaded=20 > or need to do load balance.=20 > In summary:=20 > 1) I think the MAG can not know if the LMA obtained using DNS is the = wrong LMA. Only the LMA itself know. > 2) The only criteria to judge if the LMA is the wrong LMA is based on = load balance consideration. You can reason it in this way. However, I don't think we should = explicitly state overload/load balancing as the only reason why to = runtime assignment.=20 - Jouni [snap]= From behcetsarikaya@yahoo.com Tue Apr 27 07:25:56 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5CB28C20D for ; Tue, 27 Apr 2010 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.485 X-Spam-Level: X-Spam-Status: No, score=0.485 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USn79uJijn0J for ; Tue, 27 Apr 2010 07:25:55 -0700 (PDT) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id B452728C211 for ; Tue, 27 Apr 2010 07:19:43 -0700 (PDT) Received: (qmail 20865 invoked by uid 60001); 27 Apr 2010 14:19:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1272377969; bh=ETC0J71fznsnNN99hW1Ex4W9RBcisA5t0E5+CJJ1xQM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=J4UVesNvGcojgBzs2sSEgUs/PKTo8EhzPGMFXSlb9rZqYxKjBBHaJpXFx2IZdcaPcOwKajwIJeqMTE9HmjOIQLWBiM8N9Ux32vJcY4U0G9Rrua1XSRj3KoT4BkI8bZW6aEDEExt4obzoTf1MQBJaLiScUwhPG+SAY+K292caQBM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dOZfi72v+dePhMk4aeeYGn5P9hjnb4WtqmOzVmG3jJaWQRNqG8XxzGzIkje7B9yJZLd2DKKMW7fHQ9+loX6WymluQal4F2beg3qFcqlgP156QRs96uJmXj8jX2kMlGg5gIASVtys+32y+1g0xmfWilTctXWI+hN6qDfAe8DQTOA=; Message-ID: <249347.19484.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: jgOv4SYVM1l33DzHYkiWD8l2Yiq_.pdOuTXb14e5nnqPA7s rmU0N5V7Y056Bphq66VgTMY6EI.p0f3UPqJODUtZTSSjx6lzrAPazvihqu_b CxmBocBw9j0DUb0m2UhYpPCUfR9g_V40pHVVPUH0LK49bK4oKWSTBbD9oHga IygX4VXH70MrcJ1SYrxjjRwYHoyXfCl6h1n9Ga4eVgFVFY5ogUX8VQ0vt5E. RHjWmcEBpE5auTxY5_0olHmPKKFSEC41LFvKU_a0E41Th_dKhnAiZCSNXJsC 5eFn5inhj3514HNLJZZ9EPvqFSfnU8GR0.ScCs7KEbfUUSRvws1v5YLgx5ha bHvXMT7e9Tm3aBHrxYQ-- Received: from [94.96.14.151] by web111408.mail.gq1.yahoo.com via HTTP; Tue, 27 Apr 2010 07:19:29 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.103.269680 References: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> <4BD5D7CC.3010603@piuha.net> Date: Tue, 27 Apr 2010 07:19:29 -0700 (PDT) From: Behcet Sarikaya To: Jari Arkko , Ahmad Muhanna In-Reply-To: <4BD5D7CC.3010603@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 14:25:56 -0000 I support sending this unsolicited LS to 3GPP. Regards, Behcet ----- Original Message ---- > From: Jari Arkko > To: Ahmad Muhanna > Cc: "netext@ietf.org" ; "Basavaraj.Patil@nokia.com" > Sent: Mon, April 26, 2010 1:13:32 PM > Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP > > Ahmad, > I think we are setting a precedence here. I am not aware of > IETF sending unsolicited LSes; but I could be wrong. > We > do send many unsolicited liaison statements. For instance, when we wish to > inform someone officially that something is happening, when we are worried about > some development in some other SDO wrt IETF conflicts, etc. (The only > question is whether we are providing interesting information in this case. > Basavaraj and Rajeev have told me that there is some unclarity about NETEXT's > mission. I have not observed that myself, but I also do not have an issue in > informing 3GPP of ongoing work.) 3GPP - IETF management teleconferences > are another way to send messages, but they do not necessarily always have the > right people in the call. E.g., SA2 chairs do not participate them IIRC. In any > case, the regular teleconferences are typically held maybe a month before the > IETF, so there's probably some time still for the next one. The preferred > method of informing other SDOs of ongoing work is joint participation, of > course. We can supplement that with liaison statements and other tools where > needed. Jari _______________________________________________ netext > mailing list > href="mailto:netext@ietf.org">netext@ietf.org > href="https://www.ietf.org/mailman/listinfo/netext" target=_blank > >https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Tue Apr 27 08:36:45 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A08D28C226 for ; Tue, 27 Apr 2010 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.272 X-Spam-Level: X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvoxh3aT8fbQ for ; Tue, 27 Apr 2010 08:36:44 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7EB6F28C23F for ; Tue, 27 Apr 2010 08:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1272382246; x=1303918246; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20,=20Ahmad=20M uhanna=0D=0A=09|CC:=20"Basava raj.Patil@nokia.com"=20,=0D=0A =09"rkoodli@cisco.com"=20,=20"netext@i etf.org"=20|Date:=20Tue,=2027=20Apr=2020 10=2008:30:10=20-0700|Subject:=20RE:=20[netext]=20Liaison =20Statement=20on=20Flow=20Mobility=20to=203GPP |Thread-Topic:=20[netext]=20Liaison=20Statement=20on=20Fl ow=20Mobility=20to=203GPP|Thread-Index:=20AcrlbDE84Jsy2Qa eQRKefJ34n8N5aQAr99tQ|Message-ID:=20 |References:=20=0D=0A=09=0D=0A=20<1FCAE7B6027FE3489B8497A0 60C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se>=0D=0A =20<4BD5D7CC.3010603@piuha.net>|In-Reply-To:=20<4BD5D7CC. 3010603@piuha.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=czwrSVLqBVdSzO3IF6T2m94azMZxtGmkOquLUXfjBoo=; b=xEMb70RhEuZOs4O8IesyMboMNxw0hFQe1VH8Dbjht3fJr6nJ64XggDf7 zvl+nb3sAXI8MR8V7eFLGBafTPJlHBztjy4TmevVXPhG6rl64fGcdHamf U0hUt5ZhA4P1/reeonJpxzty5hCGlIKuGfb5YrmtpYoi106mxkD7dBGnP 4=; X-IronPort-AV: E=McAfee;i="5400,1158,5965"; a="39820764" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 27 Apr 2010 08:30:13 -0700 X-IronPort-AV: E=Sophos;i="4.52,277,1270450800"; d="scan'208";a="18720543" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 27 Apr 2010 08:30:13 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 27 Apr 2010 08:30:13 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.689.0; Tue, 27 Apr 2010 08:30:12 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 27 Apr 2010 08:30:12 -0700 From: "Laganier, Julien" To: Jari Arkko , Ahmad Muhanna Date: Tue, 27 Apr 2010 08:30:10 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrlbDE84Jsy2QaeQRKefJ34n8N5aQAr99tQ Message-ID: References: <1FCAE7B6027FE3489B8497A060C704C4261B925DBF@EUSAACMS0714.eamcs.ericsson.se> <4BD5D7CC.3010603@piuha.net> In-Reply-To: <4BD5D7CC.3010603@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 15:36:45 -0000 Jari, Jari Arkko wrote: >=20 > (The only question is whether we are providing interesting information > in this case. Basavaraj and Rajeev have told me that there is some > unclarity about NETEXT's mission. I have not observed that myself, but > I also do not have an issue in informing 3GPP of ongoing work.) I disagree that there is some unclarity about NETEXT's mission within SA2 W= G as Cisco has provided to the SA2 WG an informational update highlighting = the fact that the NETEXT had been rechartered to work on flow mobility, and= that was discussed and noted.=20 Also, to the extent that SA2 would indeed be unclear about NETEXT's mission= (I don't think so but anyway) I do not believe that the draft LS on the ta= ble constitute an appropriate remedy to that unclarity. --julien From rkoodli@cisco.com Tue Apr 27 11:01:37 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0EC03A6A90 for ; Tue, 27 Apr 2010 11:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7lm4EDf6HLg for ; Tue, 27 Apr 2010 11:01:36 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DB6EB28C18C for ; Tue, 27 Apr 2010 11:01:27 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAHbD1kutJV2Z/2dsb2JhbACcTAJxp1qaHIJMgkIEgzqIbg X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105603713" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2010 18:01:14 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o3RI1EpA013894; Tue, 27 Apr 2010 18:01:14 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Apr 2010 13:58:38 -0400 Received: from 171.70.249.106 ([171.70.249.106]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 17:58:38 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 11:03:26 -0700 From: Rajeev Koodli To: Jari Arkko , Ahmad Muhanna Message-ID: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrmM+7xcRwGvRK0iEiyT8fDVJnSpQ== In-Reply-To: <4BD5D7CC.3010603@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2010 17:58:38.0537 (UTC) FILETIME=[439A0B90:01CAE633] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:01:38 -0000 All, On 4/26/10 11:13 AM, "Jari Arkko" wrote: > (The only question is whether we are providing interesting information > in this case. Basavaraj and Rajeev have told me that there is some > unclarity about NETEXT's mission. I have not observed that myself, but I > also do not have an issue in informing 3GPP of ongoing work.) > FYI: see the discussion around TD S2-101028 and TD S2-101699 in http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_78_San_Francisco/Report/S2_78_ Draft_Rep_v010.zip This is not meant to debate the minutes of SA2 meeting here, but FYI. You can see that there are *companies* arguing about the flow mobility work in IETF. The LS is intended to provide an official Informative IETF statement about the status of flow mobility work in IETF. ............................... TD S2-101028 Proposed conclusion on MAPIM TR. This was introduced by Qualcomm Incorporated. This document proposes a change in the conclusions of the TR. Discussion and conclusion: Intel commented that the arguments given were in some cases biased and in other cases technically wrong and noted that this had been proposed before to SA WG2. Intel did not think the work on network-based solutions should be stopped and the TR should remain open so that interested companies can continue to contribute to solutions. NEC also commented that there was bias and technical errors in the contribution and did not think companies with no interest in network-based solutions should be able to block the work of interested companies. Qualcomm Incorporated replied that there was no intension to block work on network-based solutions, but highlighted that the work done so far had not produced anything that can be feasibly deployed. Nokia Siemens Networks commented that the analysis in this contribution was considered accurate and that it is complex to include such functionality in the terminal. Nokia Siemens Networks suggested waiting until adequate progress has been made in the IETF and there is sufficient demand for this from 3GPP member companies. R.I.M also supported this analysis from the terminal viewpoint. The SA WG2 Chairman commented that in order to do any normative work in this area a new WID would need to be agreed, which did not appear likely at present, but the TR could be left open. Companies were asked to continue to discuss this issue off-line and this would not be given much SA WG2 meeting time unless there is a breakthrough on the progress for this. This contribution was then noted. TD S2-101699 IETF Network-Based Flow Mobility Status Update. This was introduced by Cisco Systems on behalf of Cisco Systems, Intel, Huawei, ZTE, China Mobile and Samsung. Provides an update of recent activity in the IETF in support of network based flow mobility. Discussion and conclusion: Telecom Italia commented that the use of this in 3GPP would depend upon 3GPP operator support for PMIPv6, which has not been the case in recent discussions. R.I.M commented that the timescales for the IETF work is also not known and the TR should not be kept open awaiting the IETF protocol. NTT DOCOMO commented that operators have an interest in IP Flow Mobility. Qualcomm commented that the proposed charter for IETF work contains milestones which are not included in this contribution and some of the implications of this document are not accurate. This was provided for information and was noted. From rkoodli@cisco.com Tue Apr 27 11:04:44 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6CD3A6A89 for ; Tue, 27 Apr 2010 11:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.455 X-Spam-Level: X-Spam-Status: No, score=-7.455 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYTl3OY-JU+0 for ; Tue, 27 Apr 2010 11:04:43 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1A7E63A69B4 for ; Tue, 27 Apr 2010 11:04:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAGfE1kutJV2c/2dsb2JhbACcTAJxp2iaHIUOBIM6iG4 X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105743695" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2010 18:04:29 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o3RI4TJ0025311; Tue, 27 Apr 2010 18:04:29 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Apr 2010 14:01:53 -0400 Received: from 171.70.249.106 ([171.70.249.106]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 18:01:53 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 11:06:41 -0700 From: Rajeev Koodli To: "Laganier, Julien" , Jari Arkko , Ahmad Muhanna Message-ID: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrlbDE84Jsy2QaeQRKefJ34n8N5aQAr99tQAAYUof0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2010 18:01:53.0674 (UTC) FILETIME=[B7E996A0:01CAE633] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:04:44 -0000 Hi Julien, As you point out, it was a contribution from *Cisco and others* that was presented at noted. There was discussion. There was also a contribution from Qualcomm which some companies thought was meant to close the work related to flow mobility (with no specific solution for PMIP6) in 3GPP. There was discussion about that as well. (See my other email for a reference to the minutes, which you have probably already seen) It is exactly this kind of back-and-forth about the status of flow mobility work in NetExt this LS is trying to address, by providing an official IETF LS, rather than company contributions. You have made your point pretty clear, as before, about your opposition. And, your point is noted. Thanks, -Rajeev On 4/27/10 8:30 AM, "Laganier, Julien" wrote: > Jari, > > Jari Arkko wrote: >> >> (The only question is whether we are providing interesting information >> in this case. Basavaraj and Rajeev have told me that there is some >> unclarity about NETEXT's mission. I have not observed that myself, but >> I also do not have an issue in informing 3GPP of ongoing work.) > > I disagree that there is some unclarity about NETEXT's mission within SA2 WG > as Cisco has provided to the SA2 WG an informational update highlighting the > fact that the NETEXT had been rechartered to work on flow mobility, and that > was discussed and noted. > > Also, to the extent that SA2 would indeed be unclear about NETEXT's mission (I > don't think so but anyway) I do not believe that the draft LS on the table > constitute an appropriate remedy to that unclarity. > > --julien From julienl@qualcomm.com Tue Apr 27 12:39:25 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747913A69FA for ; Tue, 27 Apr 2010 12:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.287 X-Spam-Level: X-Spam-Status: No, score=-106.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBN5B-mMYeEb for ; Tue, 27 Apr 2010 12:39:24 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 367DA3A69C1 for ; Tue, 27 Apr 2010 12:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1272397151; x=1303933151; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Rajeev=20Koodli=20,=20Jari=20Ar kko=20,=0D=0A=09Ahmad=20Muhanna=20< ahmad.muhanna@ericsson.com>|CC:=20"Basavaraj.Patil@nokia. com"=20,=20"netext@ietf.org" =0D=0A=09|Date:=20Tue,=2027=20Apr=202010 =2012:38:53=20-0700|Subject:=20RE:=20[netext]=20Liaison =20Statement=20on=20Flow=20Mobility=20to=203GPP |Thread-Topic:=20[netext]=20Liaison=20Statement=20on=20Fl ow=20Mobility=20to=203GPP|Thread-Index:=20AcrlbDE84Jsy2Qa eQRKefJ34n8N5aQAr99tQAAYUof0AAhJxgA=3D=3D|Message-ID:=20< BF345F63074F8040B58C00A186FCA57F1EFEFD745D@NALASEXMB04.na .qualcomm.com>|References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=CZeQwBDB8YjX5zuI4bGg5BNPkj4AVU+JkvjSXQzQD4E=; b=CX/bbFyHv6TFqiPrkM9t6PbXO0XHLR8/qjtJBQ2lZry/E8hf1sgzCugD c2QpnuzRw25Csi4VpoWBMoq5w9STLhMCFJfw9hOMS2VZLxwK+PZl6EbVk aBJhr+V/RPq3fNmeSPjar9n2MOYGij4Onv94zFBaM+4dcy8r0jkFImvcb I=; X-IronPort-AV: E=McAfee;i="5400,1158,5965"; a="39841234" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 27 Apr 2010 12:38:56 -0700 X-IronPort-AV: E=Sophos;i="4.52,280,1270450800"; d="scan'208";a="19105339" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 27 Apr 2010 12:38:56 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 27 Apr 2010 12:38:56 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 27 Apr 2010 12:38:56 -0700 From: "Laganier, Julien" To: Rajeev Koodli , Jari Arkko , Ahmad Muhanna Date: Tue, 27 Apr 2010 12:38:53 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrlbDE84Jsy2QaeQRKefJ34n8N5aQAr99tQAAYUof0AAhJxgA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 19:39:25 -0000 Rajeev, IMHO it is misleading that you are quoting parts of a 3GPP report out of co= ntext. The 3GPP contribution from Qualcomm was not meant to close the work = related to flow mobility, it was meant to close a 3GPP study item that has = already been ongoing for more than one year, and all 3GPP study items are m= eant to conclude. Also, this proposal was justified by a 3GPP-centric technical analysis (e.g= ., in terms of initiating endpoint, network/operator control, network/termi= nal impact), and thus unrelated to the status of the flow mobility work in = the IETF. You referring to this discussion as a "kind of back-and-forth abo= ut the status of flow mobility work in NetExt" supposedly lead by Qualcomm = is thus factually incorrect and inappropriate. Please also note that I have commented that the current content of LS is in= appropriate. Thank you. --julien Rajeev Koodli wrote: >=20 > Hi Julien, >=20 > As you point out, it was a contribution from *Cisco and others* that > was presented at noted. There was discussion. There was also a contributi= on > from Qualcomm which some companies thought was meant to close the work > related to flow mobility (with no specific solution for PMIP6) in 3GPP. > There was discussion about that as well. (See my other email for a refere= nce to > the minutes, which you have probably already seen) >=20 > It is exactly this kind of back-and-forth about the status of flow > mobility work in NetExt this LS is trying to address, by providing an off= icial > IETF LS, rather than company contributions. >=20 > You have made your point pretty clear, as before, about your opposition. > And, your point is noted. >=20 > Thanks, >=20 > -Rajeev >=20 >=20 >=20 > On 4/27/10 8:30 AM, "Laganier, Julien" wrote: >=20 > > Jari, > > > > Jari Arkko wrote: > >> > >> (The only question is whether we are providing interesting > information > >> in this case. Basavaraj and Rajeev have told me that there is some > >> unclarity about NETEXT's mission. I have not observed that myself, > but > >> I also do not have an issue in informing 3GPP of ongoing work.) > > > > I disagree that there is some unclarity about NETEXT's mission within > SA2 WG > > as Cisco has provided to the SA2 WG an informational update > highlighting the > > fact that the NETEXT had been rechartered to work on flow mobility, > and that > > was discussed and noted. > > > > Also, to the extent that SA2 would indeed be unclear about NETEXT's > mission (I > > don't think so but anyway) I do not believe that the draft LS on the > table > > constitute an appropriate remedy to that unclarity. > > > > --julien From xiayangsong@huawei.com Tue Apr 27 12:56:37 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344643A69C1 for ; Tue, 27 Apr 2010 12:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.176 X-Spam-Level: * X-Spam-Status: No, score=1.176 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFap-EPmL05o for ; Tue, 27 Apr 2010 12:56:32 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6C5303A6993 for ; Tue, 27 Apr 2010 12:56:31 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1J0024GWPK2T@szxga04-in.huawei.com> for netext@ietf.org; Wed, 28 Apr 2010 03:56:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1J00M8TWPK01@szxga04-in.huawei.com> for netext@ietf.org; Wed, 28 Apr 2010 03:56:08 +0800 (CST) Received: from X24512z ([10.124.12.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1J00BUBWPHFL@szxml06-in.huawei.com> for netext@ietf.org; Wed, 28 Apr 2010 03:56:08 +0800 (CST) Date: Tue, 27 Apr 2010 14:56:05 -0500 From: Frank Xia In-reply-to: To: 'Rajeev Koodli' , netext@ietf.org Message-id: <00ac01cae643$ad6bc940$510c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_tVHihs62fjgCWg/r2tKo3Q)" Thread-index: Acrf9vKv/KT/1NVEMkaH9jfbV9e/2AGS2b7g References: Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 19:56:37 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tVHihs62fjgCWg/r2tKo3Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Chairs and Jari It is a good idea to send this to 3GPP. As far as I remember, there was a long debate in Netext regarding flow mobility for PMIP. Some 3GPP colleagues also attended. This email can serve as a clarification or summarization. The community as a whole needs a clear directional signal. BR Frank From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli Sent: Monday, April 19, 2010 2:32 PM To: netext@ietf.org Subject: [netext] Liaison Statement on Flow Mobility to 3GPP FYI..Jari and the chairs are planning to send the following LS to 3GPP informing them of NetExt's work on Flow Mobility. Please provide comments, if any.. Thanks, -Rajeev .................................... April 14, 2010 To: 3GPP SA2 Chairman: Balazs Bertenyi Vice chairman: Andy Bennett Vice chairman: Hong Liu Subject: Flow mobility feature being specified for Proxy Mobile IPv6 (RFC5213) in the NetExt WG Dear Balazs, Andy and, Hong, We would like to inform you about the work being done on extending Proxy Mobile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the IETF. The NetExt WG charter was revised and approved in February 2010 with the following new goal and milestone: 1. Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces - Oct 2010 Please consider this as an informative update for SA2 on the developments in NetExt WG in the IETF. Best Regards, IETF NetExt WG chairs IETF Internet area director Rajeev Koodli Jari Arkko Basavaraj Patil --Boundary_(ID_tVHihs62fjgCWg/r2tKo3Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable Liaison Statement on Flow Mobility to 3GPP

 <= /span>

Hi Chairs and = Jari

 

It is a good idea to send this to = 3GPP.

 

As far as I remember, there was a long debate = in

Netext regarding flow mobility for = PMIP.

Some 3GPP colleagues also = attended.

 

This email can serve as a clarification or =

summarization.  The community as a whole =

needs a clear directional = signal.

 

BR

Frank

 

 

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Monday, April 19, = 2010 2:32 PM
To: netext@ietf.org
Subject: [netext] Liaison Statement on Flow Mobility to 3GPP

 


FYI..Jari and the chairs are planning to send the following LS to 3GPP informing them of NetExt’s work on Flow Mobility.
Please provide comments, if any..

Thanks,

-Rajeev
....................................
 

April 14, 2010
 
To: 3GPP SA2
            &= nbsp;     Chairman: Balazs Bertenyi
            &= nbsp;     Vice chairman: Andy Bennett
            &= nbsp;     Vice chairman: Hong Liu
 
Subject:  Flow mobility feature = being specified for Proxy Mobile IPv6 = (RFC5213) in the NetExt WG

Dear Balazs, Andy and, Hong,

We would like to inform you about the work being done on extending Proxy = Mobile IPv6 (RFC5213) to support flow mobility within the NetExt WG in the = IETF. The NetExt WG charter was revised and approved in February 2010 with the = following new goal and milestone:

1.    Initial WG document(s) on Proxy Mobile IPv6 = Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface = over Multiple Physical Interfaces – Oct 2010  

Please consider this as an informative update for SA2 on the = developments in NetExt WG in the IETF.

Best Regards,

IETF NetExt WG chairs             &= nbsp;        IETF Internet area director
Rajeev Koodli             &= nbsp;           &n= bsp;           Jar= i Arkko
Basavaraj Patil

--Boundary_(ID_tVHihs62fjgCWg/r2tKo3Q)-- From rkoodli@cisco.com Tue Apr 27 13:01:26 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8C93A6A2B for ; Tue, 27 Apr 2010 13:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.575 X-Spam-Level: X-Spam-Status: No, score=-7.575 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TALMQ2hUJJzx for ; Tue, 27 Apr 2010 13:01:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D62813A69C6 for ; Tue, 27 Apr 2010 13:01:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAFvf1kutJV2b/2dsb2JhbACcUAJxpx2aFoUOBIM6iG4 X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105646091" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2010 20:01:11 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o3RK1BEG012411; Tue, 27 Apr 2010 20:01:11 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Apr 2010 15:58:35 -0400 Received: from 171.70.249.106 ([171.70.249.106]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 19:58:34 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 13:03:23 -0700 From: Rajeev Koodli To: "Laganier, Julien" , Jari Arkko , Ahmad Muhanna Message-ID: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrlbDE84Jsy2QaeQRKefJ34n8N5aQAr99tQAAYUof0AAhJxgAACAPAg In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2010 19:58:35.0380 (UTC) FILETIME=[05412340:01CAE644] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:01:27 -0000 Julien, You can see the minutes for yourself in the other email. You can also see the discussion about flow mobility there. On 4/27/10 12:38 PM, "Laganier, Julien" wrote: > Rajeev, > > IMHO it is misleading that you are quoting parts of a 3GPP report out of > context. The 3GPP contribution from Qualcomm was not meant to close the work > related to flow mobility, it was meant to close a 3GPP study item that has > already been ongoing for more than one year, and all 3GPP study items are > meant to conclude. > > Also, this proposal was justified by a 3GPP-centric technical analysis (e.g., > in terms of initiating endpoint, network/operator control, network/terminal > impact), and thus unrelated to the status of the flow mobility work in the > IETF. You referring to this discussion as a "kind of back-and-forth about the > status of flow mobility work in NetExt" supposedly lead by Qualcomm is thus > factually incorrect and inappropriate. > > Please also note that I have commented that the current content of LS is > inappropriate. > > Thank you. > > --julien > > Rajeev Koodli wrote: >> >> Hi Julien, >> >> As you point out, it was a contribution from *Cisco and others* that >> was presented at noted. There was discussion. There was also a contribution >> from Qualcomm which some companies thought was meant to close the work >> related to flow mobility (with no specific solution for PMIP6) in 3GPP. >> There was discussion about that as well. (See my other email for a reference >> to >> the minutes, which you have probably already seen) >> >> It is exactly this kind of back-and-forth about the status of flow >> mobility work in NetExt this LS is trying to address, by providing an >> official >> IETF LS, rather than company contributions. >> >> You have made your point pretty clear, as before, about your opposition. >> And, your point is noted. >> >> Thanks, >> >> -Rajeev >> >> >> >> On 4/27/10 8:30 AM, "Laganier, Julien" wrote: >> >>> Jari, >>> >>> Jari Arkko wrote: >>>> >>>> (The only question is whether we are providing interesting >> information >>>> in this case. Basavaraj and Rajeev have told me that there is some >>>> unclarity about NETEXT's mission. I have not observed that myself, >> but >>>> I also do not have an issue in informing 3GPP of ongoing work.) >>> >>> I disagree that there is some unclarity about NETEXT's mission within >> SA2 WG >>> as Cisco has provided to the SA2 WG an informational update >> highlighting the >>> fact that the NETEXT had been rechartered to work on flow mobility, >> and that >>> was discussed and noted. >>> >>> Also, to the extent that SA2 would indeed be unclear about NETEXT's >> mission (I >>> don't think so but anyway) I do not believe that the draft LS on the >> table >>> constitute an appropriate remedy to that unclarity. >>> >>> --julien > From julienl@qualcomm.com Tue Apr 27 13:09:05 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1268D3A69C6 for ; Tue, 27 Apr 2010 13:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.3 X-Spam-Level: X-Spam-Status: No, score=-106.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOoa2hC4KUwY for ; Tue, 27 Apr 2010 13:09:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A60943A6774 for ; Tue, 27 Apr 2010 13:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1272398928; x=1303934928; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Rajeev=20Koodli=20,=20Jari=20Ar kko=20,=0D=0A=09Ahmad=20Muhanna=20< ahmad.muhanna@ericsson.com>|CC:=20"Basavaraj.Patil@nokia. com"=20,=20"netext@ietf.org" =0D=0A=09|Date:=20Tue,=2027=20Apr=202010 =2013:08:45=20-0700|Subject:=20RE:=20[netext]=20Liaison =20Statement=20on=20Flow=20Mobility=20to=203GPP |Thread-Topic:=20[netext]=20Liaison=20Statement=20on=20Fl ow=20Mobility=20to=203GPP|Thread-Index:=20AcrlbDE84Jsy2Qa eQRKefJ34n8N5aQAr99tQAAYUof0AAhJxgAACAPAgAAAHAzA=3D |Message-ID:=20|References:=20=0D=0A=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ADfv0ScR79EzKUo7Os0CMQfZUrADvbbEgAPLCZZKK8o=; b=TPh7RrqHgsV8GJUuN0xw314lBlnDT+AUcw5D1WSpcp1n+q/ij4rlk15E TX1VI5ry4AhrC90OTVBPd4q7hJxAudl0pqV/W6tRm7tZsU6cpZOXLdLEu +hfNt6VyyfL6AAtUfS+lpVjoLfyMF1yygtzm2CUVVUaGm9YcehSgD0xd2 s=; X-IronPort-AV: E=McAfee;i="5400,1158,5965"; a="39843601" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine01.qualcomm.com with ESMTP; 27 Apr 2010 13:08:48 -0700 X-IronPort-AV: E=Sophos;i="4.52,282,1270450800"; d="scan'208";a="28717486" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 27 Apr 2010 13:08:48 -0700 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 27 Apr 2010 13:08:48 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.0.689.0; Tue, 27 Apr 2010 13:08:47 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Tue, 27 Apr 2010 13:08:46 -0700 From: "Laganier, Julien" To: Rajeev Koodli , Jari Arkko , Ahmad Muhanna Date: Tue, 27 Apr 2010 13:08:45 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrlbDE84Jsy2QaeQRKefJ34n8N5aQAr99tQAAYUof0AAhJxgAACAPAgAAAHAzA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:09:05 -0000 Rajeev, Rajeev Koodli wrote: >=20 > Julien, >=20 > You can see the minutes for yourself in the other email. You can also > see the discussion about flow mobility there. In case I wasn't clear enough -- In my previous message I was specifically = referring to that other email of yours quoting parts of a 3GPP report out o= f context. --julien > On 4/27/10 12:38 PM, "Laganier, Julien" wrote: >=20 > > Rajeev, > > > > IMHO it is misleading that you are quoting parts of a 3GPP report out > > of context. The 3GPP contribution from Qualcomm was not meant to close > > the work related to flow mobility, it was meant to close a 3GPP study > > item that has already been ongoing for more than one year, and all 3GPP > > study items are meant to conclude. > > > > Also, this proposal was justified by a 3GPP-centric technical analysis = (e.g., > > in terms of initiating endpoint, network/operator control, network/term= inal > > impact), and thus unrelated to the status of the flow mobility work in = the > > IETF. You referring to this discussion as a "kind of back-and-forth abo= ut the > > status of flow mobility work in NetExt" supposedly lead by Qualcomm is = thus > > factually incorrect and inappropriate. > > > > Please also note that I have commented that the current content of LS i= s > > inappropriate. > > > > Thank you. > > > > --julien > > > > Rajeev Koodli wrote: > >> > >> Hi Julien, > >> > >> As you point out, it was a contribution from *Cisco and others* that > >> was presented at noted. There was discussion. There was also a > contribution > >> from Qualcomm which some companies thought was meant to close the > work > >> related to flow mobility (with no specific solution for PMIP6) in > 3GPP. > >> There was discussion about that as well. (See my other email for a > reference > >> to > >> the minutes, which you have probably already seen) > >> > >> It is exactly this kind of back-and-forth about the status of flow > >> mobility work in NetExt this LS is trying to address, by providing > an > >> official > >> IETF LS, rather than company contributions. > >> > >> You have made your point pretty clear, as before, about your > opposition. > >> And, your point is noted. > >> > >> Thanks, > >> > >> -Rajeev > >> > >> > >> > >> On 4/27/10 8:30 AM, "Laganier, Julien" wrote: > >> > >>> Jari, > >>> > >>> Jari Arkko wrote: > >>>> > >>>> (The only question is whether we are providing interesting > >> information > >>>> in this case. Basavaraj and Rajeev have told me that there is some > >>>> unclarity about NETEXT's mission. I have not observed that myself, > >> but > >>>> I also do not have an issue in informing 3GPP of ongoing work.) > >>> > >>> I disagree that there is some unclarity about NETEXT's mission > within > >> SA2 WG > >>> as Cisco has provided to the SA2 WG an informational update > >> highlighting the > >>> fact that the NETEXT had been rechartered to work on flow mobility, > >> and that > >>> was discussed and noted. > >>> > >>> Also, to the extent that SA2 would indeed be unclear about NETEXT's > >> mission (I > >>> don't think so but anyway) I do not believe that the draft LS on > the > >> table > >>> constitute an appropriate remedy to that unclarity. > >>> > >>> --julien > > From rkoodli@cisco.com Tue Apr 27 13:25:59 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310443A698C for ; Tue, 27 Apr 2010 13:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.67 X-Spam-Level: X-Spam-Status: No, score=-7.67 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCGATSTS0Rfc for ; Tue, 27 Apr 2010 13:25:57 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4F3E03A69C2 for ; Tue, 27 Apr 2010 13:25:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFADfl1kutJV2d/2dsb2JhbACcUgJxpwuaF4JMgkIEgzqIbg X-IronPort-AV: E=Sophos;i="4.52,283,1270425600"; d="scan'208";a="105792732" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2010 20:25:37 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o3RKPa8U026205; Tue, 27 Apr 2010 20:25:37 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Apr 2010 16:23:01 -0400 Received: from 171.70.249.106 ([171.70.249.106]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 20:23:00 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 13:27:48 -0700 From: Rajeev Koodli To: "Laganier, Julien" , Jari Arkko , Ahmad Muhanna Message-ID: Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: AcrlbDE84Jsy2QaeQRKefJ34n8N5aQAr99tQAAYUof0AAhJxgAAC2z2W In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2010 20:23:01.0028 (UTC) FILETIME=[6ED94640:01CAE647] Cc: "netext@ietf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 20:25:59 -0000 Julien, the discussion below on S2-101028 refers to the "MAPIM" work. In the SA2 minutes, it is covered under: "9.10 Study on Multi Access PDN connectivity and IP flow mobility (FS_MAPIM)" Here is the MAPIM work reference: http://www.3gpp1.net/ftp/Specs/html-info/23861.htm 23.861 TOC: 7.. Solutions for multi access PDN connectivity and IP flow mobility.. 13 7.1......... IP flow mobility solutions for S2c/H1 (DSMIPv6)......... 13 7.1.1.... Solution A: Routeing filters in DSMIPv6.... 13 7.1.1.1............ Overview........... 13 7.1.1.2............ DSMIPv6 enhancements........... 14 7.1.1.3............ PCC Enhancements........... 14 7.1.1.4............ Flows........... 15 7.1.1.4.1....... General....... 15 7.1.1.4.2....... Addition of one access to the PDN connection....... 15 7.1.1.4.3....... IP flow mobility....... 17 7.1.1.4.4....... Removal of one access from the PDN connection....... 18 7.1.1.4.5....... Addition of one access for multiple PDN connections to the same APN....... 19 7.1.1.5............ Routeing Filters........... 19 7.2......... IP flow mobility solutions for S2a (PMIPv6)......... 19 7.2.1.... Solution A: Routeing filters in PMIPv6.... 19 7.2.1.2............ Addition of one access to the PDN connection........... 19 7.2.1.3............ IP flow mobility........... 21 7.2.1.4............ Detaching from an Access........... 22 [so on..] I see flow mobility in the TOC above. What we are trying to do is to provide an Informative official LS from NetExt. As I have said, you have made your position on this (and the flow mobility work in general) very clear, and it is noted. Thank you. -Rajeev .............................. TD S2-101028 Proposed conclusion on MAPIM TR. This was introduced by Qualcomm Incorporated. This document proposes a change in the conclusions of the TR. Discussion and conclusion: Intel commented that the arguments given were in some cases biased and in other cases technically wrong and noted that this had been proposed before to SA WG2. Intel did not think the work on network-based solutions should be stopped and the TR should remain open so that interested companies can continue to contribute to solutions. NEC also commented that there was bias and technical errors in the contribution and did not think companies with no interest in network-based solutions should be able to block the work of interested companies. Qualcomm Incorporated replied that there was no intension to block work on network-based solutions, but highlighted that the work done so far had not produced anything that can be feasibly deployed. Nokia Siemens Networks commented that the analysis in this contribution was considered accurate and that it is complex to include such functionality in the terminal. Nokia Siemens Networks suggested waiting until adequate progress has been made in the IETF and there is sufficient demand for this from 3GPP member companies. R.I.M also supported this analysis from the terminal viewpoint. The SA WG2 Chairman commented that in order to do any normative work in this area a new WID would need to be agreed, which did not appear likely at present, but the TR could be left open. Companies were asked to continue to discuss this issue off-line and this would not be given much SA WG2 meeting time unless there is a breakthrough on the progress for this. This contribution was then noted. TD S2-101699 IETF Network-Based Flow Mobility Status Update. This was introduced by Cisco Systems on behalf of Cisco Systems, Intel, Huawei, ZTE, China Mobile and Samsung. Provides an update of recent activity in the IETF in support of network based flow mobility. Discussion and conclusion: Telecom Italia commented that the use of this in 3GPP would depend upon 3GPP operator support for PMIPv6, which has not been the case in recent discussions. R.I.M commented that the timescales for the IETF work is also not known and the TR should not be kept open awaiting the IETF protocol. NTT DOCOMO commented that operators have an interest in IP Flow Mobility. Qualcomm commented that the proposed charter for IETF work contains milestones which are not included in this contribution and some of the implications of this document are not accurate. This was provided for information and was noted. On 4/27/10 12:38 PM, "Laganier, Julien" wrote: > Rajeev, > > IMHO it is misleading that you are quoting parts of a 3GPP report out of > context. The 3GPP contribution from Qualcomm was not meant to close the work > related to flow mobility, it was meant to close a 3GPP study item that has > already been ongoing for more than one year, and all 3GPP study items are > meant to conclude. > > Also, this proposal was justified by a 3GPP-centric technical analysis (e.g., > in terms of initiating endpoint, network/operator control, network/terminal > impact), and thus unrelated to the status of the flow mobility work in the > IETF. You referring to this discussion as a "kind of back-and-forth about the > status of flow mobility work in NetExt" supposedly lead by Qualcomm is thus > factually incorrect and inappropriate. > > Please also note that I have commented that the current content of LS is > inappropriate. > > Thank you. > > --julien > > Rajeev Koodli wrote: >> >> Hi Julien, >> >> As you point out, it was a contribution from *Cisco and others* that >> was presented at noted. There was discussion. There was also a contribution >> from Qualcomm which some companies thought was meant to close the work >> related to flow mobility (with no specific solution for PMIP6) in 3GPP. >> There was discussion about that as well. (See my other email for a reference >> to >> the minutes, which you have probably already seen) >> >> It is exactly this kind of back-and-forth about the status of flow >> mobility work in NetExt this LS is trying to address, by providing an >> official >> IETF LS, rather than company contributions. >> >> You have made your point pretty clear, as before, about your opposition. >> And, your point is noted. >> >> Thanks, >> >> -Rajeev >> >> >> >> On 4/27/10 8:30 AM, "Laganier, Julien" wrote: >> >>> Jari, >>> >>> Jari Arkko wrote: >>>> >>>> (The only question is whether we are providing interesting >> information >>>> in this case. Basavaraj and Rajeev have told me that there is some >>>> unclarity about NETEXT's mission. I have not observed that myself, >> but >>>> I also do not have an issue in informing 3GPP of ongoing work.) >>> >>> I disagree that there is some unclarity about NETEXT's mission within >> SA2 WG >>> as Cisco has provided to the SA2 WG an informational update >> highlighting the >>> fact that the NETEXT had been rechartered to work on flow mobility, >> and that >>> was discussed and noted. >>> >>> Also, to the extent that SA2 would indeed be unclear about NETEXT's >> mission (I >>> don't think so but anyway) I do not believe that the draft LS on the >> table >>> constitute an appropriate remedy to that unclarity. >>> >>> --julien > From sunseawq@huawei.com Tue Apr 27 18:09:45 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30DE3A6A34 for ; Tue, 27 Apr 2010 18:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.146 X-Spam-Level: ** X-Spam-Status: No, score=2.146 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCFbAQJuhSZC for ; Tue, 27 Apr 2010 18:09:43 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4148C3A69A2 for ; Tue, 27 Apr 2010 18:09:42 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1K00MMDB7JSQ@szxga01-in.huawei.com> for netext@ietf.org; Wed, 28 Apr 2010 09:09:19 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1K00K7YB7J52@szxga01-in.huawei.com> for netext@ietf.org; Wed, 28 Apr 2010 09:09:19 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1K002VTB7IVM@szxml04-in.huawei.com> for netext@ietf.org; Wed, 28 Apr 2010 09:09:19 +0800 (CST) Date: Wed, 28 Apr 2010 09:09:18 +0800 From: Qin Wu To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <02cf01cae66f$6d8f32e0$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] Consensus call for adopting draft-xia-netext-radius-00 as WG document X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 01:09:46 -0000 Hi, Since Radius has been adopted by WiMAX NWG to Support PMIP mobility scheme and provide security and policy provisioning to PMIP mobility entities, I support to adopt this work. Regards! -Qin ----- Original Message ----- From: To: Sent: Friday, April 23, 2010 3:46 AM Subject: [netext] Consensus call for adopting draft-xia-netext-radius-00 as WG document > > Hello, > > At IETF77 we had consensus on adopting I-D: draft-xia-netext-radius-00 as a > WG document. > > This is a followup on the ML w.r.t the consensus reached at IETF77. > > If you have any concerns or objections to adopting this I-D as a Netext WG > document, please speak up (on the list or send a note to the chairs). > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From yokota@kddilabs.jp Wed Apr 28 01:09:43 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256F73A6AE2 for ; Wed, 28 Apr 2010 01:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zroaAy4Pu2aB for ; Wed, 28 Apr 2010 01:09:37 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 008313A6800 for ; Wed, 28 Apr 2010 01:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id AB4E6EC868; Wed, 28 Apr 2010 17:09:18 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [2001:200:601:402::145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 67ED2EC846; Wed, 28 Apr 2010 17:09:17 +0900 (JST) Received: from [127.0.0.1] (CBPC.mn.mip.kddilabs.jp [172.19.90.30]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id EE8C41BAAA; Wed, 28 Apr 2010 17:08:21 +0900 (JST) Message-ID: <4BD7ED20.7030001@kddilabs.jp> Date: Wed, 28 Apr 2010 17:09:04 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Rajeev Koodli References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:09:43 -0000 Hi all, Thanks, Rajeev. I started to realize what's behind this discussion... In S2-101028, the bottom line proposal is: "The study on possible extensions to S2a, S2b, S2c and H1 reference points can be considered concluded with the solution in section 7.1.1 being the recommended solution." This means that not only S2c, but also S2a and S2b should use DSMIPv6 solution, which is not what NetExt WG is currently tackling. Also, "Conclusion 7: ... Additionally, the changes involved are either currently unspecified by the SDO in charge (IETF), ..." This could give a wrong impression that IETF doesn't do anything on it. I think this LS is worth sending to 3GPP to officially inform them that "the changes involved" is being actively discussed to specify in a pragmatic manner. Just my 2 cents, -- Hidetoshi (2010/04/28 5:27), Rajeev Koodli wrote: > > Julien, > > the discussion below on S2-101028 refers to the "MAPIM" work. > In the SA2 minutes, it is covered under: > > "9.10 Study on Multi Access PDN connectivity and IP flow mobility > (FS_MAPIM)" > > Here is the MAPIM work reference: > http://www.3gpp1.net/ftp/Specs/html-info/23861.htm > > 23.861 TOC: > > 7.. Solutions for multi access PDN connectivity and IP flow mobility.. 13 > 7.1......... IP flow mobility solutions for S2c/H1 (DSMIPv6)......... 13 > 7.1.1.... Solution A: Routeing filters in DSMIPv6.... 13 > 7.1.1.1............ Overview........... 13 > 7.1.1.2............ DSMIPv6 enhancements........... 14 > 7.1.1.3............ PCC Enhancements........... 14 > 7.1.1.4............ Flows........... 15 > 7.1.1.4.1....... General....... 15 > 7.1.1.4.2....... Addition of one access to the PDN connection....... 15 > 7.1.1.4.3....... IP flow mobility....... 17 > 7.1.1.4.4....... Removal of one access from the PDN connection....... 18 > 7.1.1.4.5....... Addition of one access for multiple PDN connections to the > same APN....... 19 > 7.1.1.5............ Routeing Filters........... 19 > 7.2......... IP flow mobility solutions for S2a (PMIPv6)......... 19 > 7.2.1.... Solution A: Routeing filters in PMIPv6.... 19 > 7.2.1.2............ Addition of one access to the PDN connection........... > 19 > 7.2.1.3............ IP flow mobility........... 21 > 7.2.1.4............ Detaching from an Access........... 22 > > [so on..] > > > I see flow mobility in the TOC above. > > What we are trying to do is to provide an Informative official LS from > NetExt. As I have said, you have made your position on this (and the flow > mobility work in general) very clear, and it is noted. > > Thank you. > > -Rajeev > > > > .............................. > > TD S2-101028 Proposed conclusion on MAPIM TR. This was introduced by > Qualcomm Incorporated. This document proposes a change in the conclusions of > the TR. > > Discussion and conclusion: > Intel commented that the arguments given were in some cases biased and in > other cases technically wrong and noted that this had been proposed before > to SA WG2. Intel did not think the work on network-based solutions should be > stopped and the TR should remain open so that interested companies can > continue to contribute to solutions. NEC also commented that there was bias > and technical errors in the contribution and did not think companies with no > interest in network-based solutions should be able to block the work of > interested companies. Qualcomm Incorporated replied that there was no > intension to block work on network-based solutions, but highlighted that the > work done so far had not produced anything that can be feasibly deployed. > Nokia Siemens Networks commented that the analysis in this contribution was > considered accurate and that it is complex to include such functionality in > the terminal. Nokia Siemens Networks suggested waiting until adequate > progress has been made in the IETF and there is sufficient demand for this > from 3GPP member companies. R.I.M also supported this analysis from the > terminal viewpoint. > The SA WG2 Chairman commented that in order to do any normative work in this > area a new WID would need to be agreed, which did not appear likely at > present, but the TR could be left open. Companies were asked to continue to > discuss this issue off-line and this would not be given much SA WG2 meeting > time unless there is a breakthrough on the progress for this. This > contribution was then noted. > > > TD S2-101699 IETF Network-Based Flow Mobility Status Update. This was > introduced by Cisco Systems on behalf of Cisco Systems, Intel, Huawei, ZTE, > China Mobile and Samsung. Provides an update of recent activity in the IETF > in support of network based flow mobility. > > Discussion and conclusion: > Telecom Italia commented that the use of this in 3GPP would depend upon 3GPP > operator support for PMIPv6, which has not been the case in recent > discussions. R.I.M commented that the timescales for the IETF work is also > not known and the TR should not be kept open awaiting the IETF protocol. NTT > DOCOMO commented that operators have an interest in IP Flow Mobility. > Qualcomm commented that the proposed charter for IETF work contains > milestones which are not included in this contribution and some of the > implications of this document are not accurate. This was provided for > information and was noted. > > > On 4/27/10 12:38 PM, "Laganier, Julien" wrote: > >> Rajeev, >> >> IMHO it is misleading that you are quoting parts of a 3GPP report out of >> context. The 3GPP contribution from Qualcomm was not meant to close the work >> related to flow mobility, it was meant to close a 3GPP study item that has >> already been ongoing for more than one year, and all 3GPP study items are >> meant to conclude. >> >> Also, this proposal was justified by a 3GPP-centric technical analysis (e.g., >> in terms of initiating endpoint, network/operator control, network/terminal >> impact), and thus unrelated to the status of the flow mobility work in the >> IETF. You referring to this discussion as a "kind of back-and-forth about the >> status of flow mobility work in NetExt" supposedly lead by Qualcomm is thus >> factually incorrect and inappropriate. >> >> Please also note that I have commented that the current content of LS is >> inappropriate. >> >> Thank you. >> >> --julien >> >> Rajeev Koodli wrote: >>> >>> Hi Julien, >>> >>> As you point out, it was a contribution from *Cisco and others* that >>> was presented at noted. There was discussion. There was also a contribution >>> from Qualcomm which some companies thought was meant to close the work >>> related to flow mobility (with no specific solution for PMIP6) in 3GPP. >>> There was discussion about that as well. (See my other email for a reference >>> to >>> the minutes, which you have probably already seen) >>> >>> It is exactly this kind of back-and-forth about the status of flow >>> mobility work in NetExt this LS is trying to address, by providing an >>> official >>> IETF LS, rather than company contributions. >>> >>> You have made your point pretty clear, as before, about your opposition. >>> And, your point is noted. >>> >>> Thanks, >>> >>> -Rajeev >>> >>> >>> >>> On 4/27/10 8:30 AM, "Laganier, Julien" wrote: >>> >>>> Jari, >>>> >>>> Jari Arkko wrote: >>>>> >>>>> (The only question is whether we are providing interesting >>> information >>>>> in this case. Basavaraj and Rajeev have told me that there is some >>>>> unclarity about NETEXT's mission. I have not observed that myself, >>> but >>>>> I also do not have an issue in informing 3GPP of ongoing work.) >>>> >>>> I disagree that there is some unclarity about NETEXT's mission within >>> SA2 WG >>>> as Cisco has provided to the SA2 WG an informational update >>> highlighting the >>>> fact that the NETEXT had been rechartered to work on flow mobility, >>> and that >>>> was discussed and noted. >>>> >>>> Also, to the extent that SA2 would indeed be unclear about NETEXT's >>> mission (I >>>> don't think so but anyway) I do not believe that the draft LS on the >>> table >>>> constitute an appropriate remedy to that unclarity. >>>> >>>> --julien >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > From julienl@qualcomm.com Wed Apr 28 16:16:31 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C2A3A6912 for ; Wed, 28 Apr 2010 16:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.324 X-Spam-Level: X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtbZh0uBAu9U for ; Wed, 28 Apr 2010 16:16:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B3EE83A68C5 for ; Wed, 28 Apr 2010 16:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1272496577; x=1304032577; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-cr-hashedpuzzle: x-cr-puzzleid:acceptlanguage:content-type: content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"draft-ietf-netext-redirect@tools.ietf.org"=0D=0A =09|CC:=20"net ext@ietf.org"=20|Date:=20Wed,=2028=20Apr =202010=2016:15:38=20-0700|Subject:=20Security=20question =20on=20anycast=20mode=20of=20draft-ietf-netext-redirect- 01|Thread-Topic:=20Security=20question=20on=20anycast=20m ode=20of=0D=0A=20draft-ietf-netext-redirect-01 |Thread-Index:=20AcrnKLbIHlrgdOL/RTmRsC8oBmFEcw=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-cr-hashedpuzzle:=205N8=3D=20AdTS =20G3rj=20JB0o=20JRv3=20JhWG=20J8nQ=20NBwW=20O1yI=20QJgn =20Q4bS=0D=0A=20S9Je=20T3c/=20VKT7=20VulY=0D=0A=20WpxQ=3B 2=3BZAByAGEAZgB0AC0AaQBlAHQAZgAtAG4AZQB0AGUAeAB0AC0AcgBlA GQAaQByAGUAYwB0AEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAD sAbgBlAHQAZQB4AHQAQABpAGUAdABmAC4AbwByAGcA=3BSosha1_v1=3B 7=3B{7545CBCE-34DE-4AF5-9F8E-687B91A1F5C8}=3BagB1AGwAaQBl AG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA=3D=3D=3BWed, =0D=0A=2028=20Apr=202010=2023:15:38=0D=0A=20GMT=3BUwBlAGM AdQByAGkAdAB5ACAAcQB1AGUAcwB0AGkAbwBuACAAbwBuACAAYQBuAHkA YwBhAHMAdAAgAG0AbwBkAGUAIABvAGYAIABkAHIAYQBmAHQALQBpAGUAd ABmAC0AbgBlAHQAZQB4AHQALQByAGUAZABpAHIAZQBjAHQALQAwADEA |x-cr-puzzleid:=20{7545CBCE-34DE-4AF5-9F8E-687B91A1F5C8} |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0; bh=atxFeeqABUFkFUTe6bmOcUI6i4nBbCwc6NxIxSxpwVE=; b=bhMu+mHswR0qUJBjX1xdJvRxL028ZR/rAArirOIP7vjrqnDaMKOE6jXi hG521pIVq+ycdb6iBrOa/Q33ssKczXFLa/MeIZ2ZPfR35blI1afmfxJfs F5fGet93Jv1l7aYClI+FWt/PkmngiiwWS8xcnKJvZi1DUvHJp4sdrsp0M c=; X-IronPort-AV: E=McAfee;i="5400,1158,5966"; a="39848600" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine02.qualcomm.com with ESMTP; 28 Apr 2010 16:15:44 -0700 X-IronPort-AV: E=Sophos;i="4.52,289,1270450800"; d="scan'208";a="29580331" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Apr 2010 16:15:45 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 28 Apr 2010 16:15:45 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 28 Apr 2010 16:15:45 -0700 From: "Laganier, Julien" To: "draft-ietf-netext-redirect@tools.ietf.org" Date: Wed, 28 Apr 2010 16:15:38 -0700 Thread-Topic: Security question on anycast mode of draft-ietf-netext-redirect-01 Thread-Index: AcrnKLbIHlrgdOL/RTmRsC8oBmFEcw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 5N8= AdTS G3rj JB0o JRv3 JhWG J8nQ NBwW O1yI QJgn Q4bS S9Je T3c/ VKT7 VulY WpxQ; 2; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAG4AZQB0AGUAeAB0AC0AcgBlAGQAaQByAGUAYwB0AEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAbgBlAHQAZQB4AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7545CBCE-34DE-4AF5-9F8E-687B91A1F5C8}; agB1AGwAaQBlAG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA==; Wed, 28 Apr 2010 23:15:38 GMT; UwBlAGMAdQByAGkAdAB5ACAAcQB1AGUAcwB0AGkAbwBuACAAbwBuACAAYQBuAHkAYwBhAHMAdAAgAG0AbwBkAGUAIABvAGYAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbgBlAHQAZQB4AHQALQByAGUAZABpAHIAZQBjAHQALQAwADEA x-cr-puzzleid: {7545CBCE-34DE-4AF5-9F8E-687B91A1F5C8} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 23:16:31 -0000 Hello, I have a security question on the anycast mode described in Section 1 of th= e draft: o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 specification does not specify how the PMIPv6 protocol should treat anycast addresses assigned to mobility agents. Although [RFC4291] now allows using anycast addresses as source addresses, it does not make much sense using anycast addresses for the MAG to the LMA communication after the initial PBU/PBA exchange. For example, a blade architecture LMA may appear to the routing system as multiple LMAs with separate unicast IP addresses and with one or more "grouping" anycast addresses. I understand from the above that a group of LMA would be addressed with a c= ommon anycast address, and the first PBU would be sent to this anycast addr= ess, and redirection would follow to one of the unicast addresses of a spec= ific LMA. If that is correct, I am wondering how will the SA between the MAG and the = anycast LMA be looked up? --julien From julienl@qualcomm.com Wed Apr 28 16:22:56 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E208C3A6358 for ; Wed, 28 Apr 2010 16:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.44 X-Spam-Level: X-Spam-Status: No, score=-106.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B-46SfUv6y8 for ; Wed, 28 Apr 2010 16:22:53 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 38FFE3A685E for ; Wed, 28 Apr 2010 16:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1272496960; x=1304032960; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Hidetoshi=20Yokota=20,=20"nete xt@ietf.org"=20|CC:=20Jari=20Arkko=20,=20"Basavaraj.Patil@nokia.com"=0D=0A =09,=20Rajeev=20Koodli=20|Date:=20Wed,=2028=20Apr=202010=2016:22:34 =20-0700|Subject:=20RE:=20[netext]=20Liaison=20Statement =20on=20Flow=20Mobility=20to=203GPP|Thread-Topic:=20[nete xt]=20Liaison=20Statement=20on=20Flow=20Mobility=20to=203 GPP|Thread-Index:=20Acrmqh2QUxjYl1WDS7Gqg4N2zJ7TIQAf3lrA |Message-ID:=20|References:=20=20<4BD7ED20.7030001@kddilabs.jp> |In-Reply-To:=20<4BD7ED20.7030001@kddilabs.jp> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=qh2lBYihMs4nY0tVyELqluO5BRFvzJ6hMBuM8/e6RCM=; b=OJRYj4La+2dNq2cIxhz7o2CyVy4LYeWvxVVAz8eJuvl+rULFTodJFvYd lMqyv0sf+ReJthabMFnmb9HLYWBuFHcNdG6wRUxE0WAQqtvzDkD0fSNYJ bdVMAKLIcvQsEoavEYveSeBaVMe86FOgXJXdc/ob8+0J4vQ0Y+IQ62/QS E=; X-IronPort-AV: E=McAfee;i="5400,1158,5966"; a="39937807" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine01.qualcomm.com with ESMTP; 28 Apr 2010 16:22:39 -0700 X-IronPort-AV: E=Sophos;i="4.52,289,1270450800"; d="scan'208";a="29583911" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Apr 2010 16:22:38 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 28 Apr 2010 16:22:38 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Wed, 28 Apr 2010 16:22:38 -0700 From: "Laganier, Julien" To: Hidetoshi Yokota , "netext@ietf.org" Date: Wed, 28 Apr 2010 16:22:34 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrmqh2QUxjYl1WDS7Gqg4N2zJ7TIQAf3lrA Message-ID: References: <4BD7ED20.7030001@kddilabs.jp> In-Reply-To: <4BD7ED20.7030001@kddilabs.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Basavaraj.Patil@nokia.com" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 23:22:56 -0000 Hello Hidetoshi, Hidetoshi Yokota wrote: >=20 > Hi all, >=20 > Thanks, Rajeev. I started to realize what's behind this discussion...=20 [...] > "Conclusion 7: ... Additionally, the changes involved are either=20 > currently unspecified by the SDO in charge (IETF), ..." I really wish we would stop to quote text from external organizations out o= f context. At minimum the beginning of the sentence you have excerpted shou= ld be quoted. It read: "Conclusion 7: Inter-system network-based mobility protocols do require cha= nges to the terminal. Additionally, the changes involved are either current= ly unspecified by the SDO in charge (IETF), [...]" =20 > This could give a wrong impression that IETF doesn't do anything on it. > I think this LS is worth sending to 3GPP to officially inform them=20 > that "the changes involved" is being actively discussed to specify in=20 > a pragmatic manner. As far as I can tell reading the NETEXT WG charter: [...] The specification of any actual link layer mechanisms is outside the scope of the working group [...] The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. =20 So it is a fact that changes to the terminal are not specified by the IETF,= and I do not know what is wrong in giving that impression. On the other hand, I think sending an LS to 3GPP that only quotes a one lin= e milestone of our charter WITHOUT any of the context describing what the m= ilestone is about could give to 3GPP the wrong impression that the IETF is = fully specifying inter-access network-based mobility, including changes to = the link and/or IP layers, while it is factually not the case. Thank you. --julien From julienl@qualcomm.com Thu Apr 29 09:02:17 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1560D3A6863 for ; Thu, 29 Apr 2010 09:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7uojUS+7dUc for ; Thu, 29 Apr 2010 09:02:16 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EF6343A6804 for ; Thu, 29 Apr 2010 09:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1272556920; x=1304092920; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Hidetoshi=20Yokota=20,=20Rajee v=20Koodli=20|CC:=20Jari=20Arkko=20,=20Ahmad=20Muhanna=0D=0A=09,=20"netext@ietf.org"=20,=0D=0A=09"Basavaraj.Patil@nokia.com"=20|Date:=20Wed,=2028=20Apr=202010=2008:24:06=20 -0700|Subject:=20RE:=20[netext]=20Liaison=20Statement=20o n=20Flow=20Mobility=20to=203GPP|Thread-Topic:=20[netext] =20Liaison=20Statement=20on=20Flow=20Mobility=20to=203GPP |Thread-Index:=20Acrmqh2QUxjYl1WDS7Gqg4N2zJ7TIQAOigYQ |Message-ID:=20|References:=20=20<4BD7ED20.7030001@kddilabs.jp> |In-Reply-To:=20<4BD7ED20.7030001@kddilabs.jp> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=lPPhXKgT8u5J/KnwURrGeOEaAYl0TSqg/6dY4B+xteA=; b=W6u0D6vsB9pX3latka2/P7hiRtEpYhkVkOx+yl8iRgkj/ng7+yLRLZOM 9kPkKKz0QbuJACO+NFdJjfAdeJ5tnJhcXsGHpUOSS99JxGU+lo1aWK2CO KKlpF8XDd0reXznFDMGhJv5V1dQfwOdP+ZqTZcLTDPC/VvV4C0mz0wiFm Y=; X-IronPort-AV: E=McAfee;i="5400,1158,5966"; a="40001654" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 29 Apr 2010 09:01:10 -0700 X-IronPort-AV: E=Sophos;i="4.52,288,1270450800"; d="scan'208";a="58351068" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Apr 2010 08:24:07 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 28 Apr 2010 08:24:08 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.689.0; Wed, 28 Apr 2010 08:24:08 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 28 Apr 2010 08:24:07 -0700 From: "Laganier, Julien" To: Hidetoshi Yokota , Rajeev Koodli Date: Wed, 28 Apr 2010 08:24:06 -0700 Thread-Topic: [netext] Liaison Statement on Flow Mobility to 3GPP Thread-Index: Acrmqh2QUxjYl1WDS7Gqg4N2zJ7TIQAOigYQ Message-ID: References: <4BD7ED20.7030001@kddilabs.jp> In-Reply-To: <4BD7ED20.7030001@kddilabs.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 16:02:17 -0000 Hello Hidetoshi, Hidetoshi Yokota wrote: >=20 > Hi all, >=20 > Thanks, Rajeev. I started to realize what's behind this discussion...=20 [...] > "Conclusion 7: ... Additionally, the changes involved are either > currently unspecified by the SDO in charge (IETF), ..." I really wish we would stop to quote text from external organizations out o= f context. At minimum the beginning of the sentence you have excerpted shou= ld be quoted. It read: "Conclusion 7: Inter-system network-based mobility protocols do require cha= nges to the terminal. Additionally, the changes involved are either current= ly unspecified by the SDO in charge (IETF), [...]" =20 > This could give a wrong impression that IETF doesn't do anything on it. > I think this LS is worth sending to 3GPP to officially inform them that > "the changes involved" is being actively discussed to specify in a > pragmatic manner. As far as I can tell reading the NETEXT WG charter: [...] The specification of any actual link layer mechanisms is outside the scope of the working group [...] The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. =20 So it is a fact that changes to the terminal are not specified by the IETF,= and I do not know what is wrong in giving that impression. On the other hand, I think sending an LS to 3GPP that only quotes a one lin= e milestone of our charter WITHOUT any of the context describing what the m= ilestone is about could give to 3GPP the wrong impression that the IETF is = fully specifying inter-access network-based mobility, including changes to = the link and/or IP layers, while it is factually not the case. Thank you. --julien From yokota@kddilabs.jp Thu Apr 29 17:24:42 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8690E3A69E9 for ; Thu, 29 Apr 2010 17:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB9u5EOPntrW for ; Thu, 29 Apr 2010 17:24:41 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 35AAA3A685E for ; Thu, 29 Apr 2010 17:24:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6ACDFEC88F; Fri, 30 Apr 2010 09:24:25 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [2001:200:601:402::145]) by mandala.kddilabs.jp (Postfix) with ESMTP id BAC42EC88A; Fri, 30 Apr 2010 09:24:24 +0900 (JST) Received: from [127.0.0.1] (unknown [172.19.90.30]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 1317C1BAAA; Fri, 30 Apr 2010 09:23:27 +0900 (JST) Message-ID: <4BDA2328.7010709@kddilabs.jp> Date: Fri, 30 Apr 2010 09:24:08 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <4BD7ED20.7030001@kddilabs.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Subject: Re: [netext] Liaison Statement on Flow Mobility to 3GPP X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 00:24:42 -0000 Hi Julien, (2010/04/29 0:24), Laganier, Julien wrote: > Hello Hidetoshi, > > Hidetoshi Yokota wrote: >> >> Hi all, >> >> Thanks, Rajeev. I started to realize what's behind this discussion... > > [...] > >> "Conclusion 7: ... Additionally, the changes involved are either >> currently unspecified by the SDO in charge (IETF), ..." > > I really wish we would stop to quote text from external organizations out of context. At minimum the beginning of the sentence you have excerpted should be quoted. It read: > > "Conclusion 7: Inter-system network-based mobility protocols do require changes to the terminal. Additionally, the changes involved are either currently unspecified by the SDO in charge (IETF), [...]" Sorry, I didn't mean to ignore the first part, but just tried to highlight the intended one. >> This could give a wrong impression that IETF doesn't do anything on it. >> I think this LS is worth sending to 3GPP to officially inform them that >> "the changes involved" is being actively discussed to specify in a >> pragmatic manner. > > As far as I can tell reading the NETEXT WG charter: > > [...] The specification of any actual link > layer mechanisms is outside the scope of the working group [...] > > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to > signal mobility related events between the host and the network. > > So it is a fact that changes to the terminal are not specified by the IETF, and I do not know what is wrong in giving that impression. I think that's where a logical interfaces comes in. A logical (or virtual) interface does not necessarily change the host IP stack. Leveraging that small bump, we may be able to provide multi-homing, inter-tech HO and flow mobility. I would rather like to give an impression to other SDOs that IETF is striving to come up with a good solution for it, so don't blame it on us for the moment:-) > On the other hand, I think sending an LS to 3GPP that only quotes a one line milestone of our charter WITHOUT any of the context describing what the milestone is about could give to 3GPP the wrong impression that the IETF is fully specifying inter-access network-based mobility, including changes to the link and/or IP layers, while it is factually not the case. My very first question to the ML may be related to this, but it seems 3GPP folks would know what they should do. Also, I think this type of LS should be as much simple as possible. If you add something, people will start speculating. Probably it would be best and safest to excerpt from the approved charter. I'm not against adding some explanation if really needed, though. Regards, -- Hidetoshi > Thank you. > > --julien > > > From jouni.nospam@gmail.com Thu Apr 29 21:25:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815FF3A69FD for ; Thu, 29 Apr 2010 21:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJWJ-d87pDRt for ; Thu, 29 Apr 2010 21:25:33 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 8A4C03A69FE for ; Thu, 29 Apr 2010 21:25:29 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so2160777fgb.13 for ; Thu, 29 Apr 2010 21:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=rtqne5kGgDfI7SYvJzn3Gf675ZNC9kdPGUWM0Nqfmcw=; b=Bf8hAbbiD47fMWm0hRUc/NSG9FMtLBO8Ywli+HoGvr1vU3Y/vmxBsodAAr8Y2i7R1Q 5K0RYQXHf3H5ZI8bV5jTF71De7jdcAPsXEUCvB4UDDpHYpi0Qou8MqtDXzBR0ZFi5Uyo 2aMoZKpbQH/xu37CrhigVgjIZDRKP5tIc9swg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=NkxfQUVDPKM9eS++6zkk117MCjZMP1LlJM+ipMTeujlLrtAz86C/rLNQld+mcHa7NP oOiJsUdEf2VG9ItzbOOiWEYznE9FWAEOaSiLt0ZtbtmFAhkunD1ehmiC2h1V5Q7trPzs e4RtR1b/YPdQ3J3rDwl2RXn+M4UjrUPDTc2MU= Received: by 10.87.1.7 with SMTP id d7mr3068078fgi.75.1272601512847; Thu, 29 Apr 2010 21:25:12 -0700 (PDT) Received: from 85-156-155-129.elisa-mobile.fi (85-156-155-129.elisa-mobile.fi [85.156.155.129]) by mx.google.com with ESMTPS id g28sm2163392fkg.28.2010.04.29.21.24.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 21:25:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 30 Apr 2010 07:16:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <83C58D2A-6A70-4B12-8E46-F0DB32F8E343@gmail.com> References: To: "Laganier, Julien" X-Mailer: Apple Mail (2.1078) Cc: "netext@ietf.org" , "draft-ietf-netext-redirect@tools.ietf.org" Subject: Re: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 04:25:36 -0000 Hi Julien, On Apr 29, 2010, at 2:15 AM, Laganier, Julien wrote: > Hello, >=20 > I have a security question on the anycast mode described in Section 1 = of the draft: >=20 > o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 > specification does not specify how the PMIPv6 protocol should > treat anycast addresses assigned to mobility agents. Although > [RFC4291] now allows using anycast addresses as source addresses, > it does not make much sense using anycast addresses for the MAG = to > the LMA communication after the initial PBU/PBA exchange. For > example, a blade architecture LMA may appear to the routing = system > as multiple LMAs with separate unicast IP addresses and with one > or more "grouping" anycast addresses. >=20 > I understand from the above that a group of LMA would be addressed = with a common anycast address, and the first PBU would be sent to this = anycast address, and redirection would follow to one of the unicast = addresses of a specific LMA. Subsequent PBUs would be sent to a unicast address of a specific LMA. >=20 > If that is correct, I am wondering how will the SA between the MAG and = the anycast LMA be looked up? In the same way as SAs for unicast addresses. If SAs are build for = anycast addresses, you basically have to fall back to manual keying of = SAs (i.e. multiple LMAs share the same keys etc) and in most cases give = up with replay protection (unless LMAs are somehow able to share = sequence number state). Other than those, there is no difference to SA = configuration or usage compared to the unicast case. - Jouni >=20 > --julien From jouni.nospam@gmail.com Thu Apr 29 21:28:29 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14393A69FD for ; Thu, 29 Apr 2010 21:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMtkPEz65I68 for ; Thu, 29 Apr 2010 21:28:28 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 89C7D3A680A for ; Thu, 29 Apr 2010 21:28:28 -0700 (PDT) Received: by fxm4 with SMTP id 4so1668625fxm.31 for ; Thu, 29 Apr 2010 21:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=0w4nlnlKDv2gB4qH7B03y64bo88zKAJywSJTAQb0+5c=; b=wysB600SQBGl+DzieDdCadOeeO5kXzeq3xoAgE9JQXR0kpG1B8u5FV2BZE8pL7+yq9 aJv4q9GOIlzhWEkvvuaFF56R8/y2kdozsBOre9boovDCcnAAo3U0eIhjGukAc6liuQKQ BfWRusuljZlLvGuiQorJ04uaVV3rk44OnKSkA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=sEnJDN23MAcFAssLy3kdzTRJUXj/DWatpQn7cWKItyoo4EWHhvJfpVxmWIp7CN7RRm ehaSYiY9rK1uoWxUeSuNXw2Frp+lZbpE2JcwftEfEFoiF7/agL5FfO/61zD4+TS+VPoW fWsJBugsi+zaUfcdm0y+HxpGM1X18dc7pCuuw= Received: by 10.103.80.8 with SMTP id h8mr797965mul.90.1272601694612; Thu, 29 Apr 2010 21:28:14 -0700 (PDT) Received: from 84-231-87-54.elisa-mobile.fi (84-231-87-54.elisa-mobile.fi [84.231.87.54]) by mx.google.com with ESMTPS id y6sm7162358mug.20.2010.04.29.21.28.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 21:28:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 30 Apr 2010 07:25:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5AC33004-D54F-43B6-AB74-F901BA7C6AF2@gmail.com> References: To: "Laganier, Julien" X-Mailer: Apple Mail (2.1078) Cc: "netext@ietf.org" , "draft-ietf-netext-redirect@tools.ietf.org" Subject: Re: [netext] Security question on anycast mode of draft-ietf-netext-redirect-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 04:28:29 -0000 Hi Julien, On Apr 29, 2010, at 2:15 AM, Laganier, Julien wrote: > Hello, >=20 > I have a security question on the anycast mode described in Section 1 = of the draft: >=20 > o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 > specification does not specify how the PMIPv6 protocol should > treat anycast addresses assigned to mobility agents. Although > [RFC4291] now allows using anycast addresses as source addresses, > it does not make much sense using anycast addresses for the MAG to > the LMA communication after the initial PBU/PBA exchange. For > example, a blade architecture LMA may appear to the routing system > as multiple LMAs with separate unicast IP addresses and with one > or more "grouping" anycast addresses. >=20 > I understand from the above that a group of LMA would be addressed = with a common anycast address, and the first PBU would be sent to this = anycast address, and redirection would follow to one of the unicast = addresses of a specific LMA. Subsequent PBUs would be sent to a unicast address of a specific LMA. >=20 > If that is correct, I am wondering how will the SA between the MAG and = the anycast LMA be looked up? In the same way as SAs for unicast addresses. If SAs are build for = anycast addresses, you basically have to fall back to manual keying of = SAs (i.e. multiple LMAs share the same keys etc) and in most cases give = up with replay protection (unless LMAs are somehow able to share = sequence number state). Other than those, there is no difference to SA = configuration or usage compared to the unicast case. - Jouni >=20 > --julien