[netext] IETF81 WG Meeting minutes

<Basavaraj.Patil@nokia.com> Wed, 10 August 2011 20:40 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 189AD11E80B3 for <netext@ietfa.amsl.com>; Wed, 10 Aug 2011 13:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id P3dl+qHHElRc for <netext@ietfa.amsl.com>; Wed, 10 Aug 2011 13:40:31 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com []) by ietfa.amsl.com (Postfix) with ESMTP id C951A11E807E for <netext@ietf.org>; Wed, 10 Aug 2011 13:40:30 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com []) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7AKexhe005342 for <netext@ietf.org>; Wed, 10 Aug 2011 23:41:02 +0300
Received: from smtp.mgd.nokia.com ([]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 23:41:00 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com ( by NOK-AM1MHUB-04.mgdnok.nokia.com ( with Microsoft SMTP Server (TLS) id; Wed, 10 Aug 2011 22:40:59 +0200
Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([]) by 008-AM1MMR1-006.mgdnok.nokia.com ([]) with mapi id 14.01.0323.002; Wed, 10 Aug 2011 22:40:59 +0200
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: IETF81 WG Meeting minutes
Thread-Index: AQHMV53PoGo9mLojrkCI5+P0dASVDA==
Date: Wed, 10 Aug 2011 20:40:59 +0000
Message-ID: <CA685708.1CE6A%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <0DA3353D219EAC44B32CB028101FCD9B@nokia.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Aug 2011 20:41:00.0242 (UTC) FILETIME=[D042C320:01CC579D]
X-Nokia-AV: Clean
Subject: [netext] IETF81 WG Meeting minutes
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2011 20:40:32 -0000


Please find below the NetExt WG meeting@IETF81 minutes. If you note any
discrepancy or errors, please do let me know and I will correct them.


Also at: http://www.ietf.org/proceedings/81/minutes/netext.txt

Network-Based Mobility Extensions WG meeting at IETF81 (Quebec, CA)

THURSDAY, July 28, 2011
1300-1500 Afternoon Session I

Chairs:  Basavaraj Patil (basavaraj.patil@nokia.com)
         Rajeev Koodli (rkoodli@cisco.com)

These meeting minutes are courtesy of:
1. Charles Perkins (charles.perkins@earthlink.net)
2. Dirk Von-Hugo  (Dirk.von-Hugo@telekom.de)


Chairs announce slight change to (latest) published agenda: PMIPv6
inter-working with WiFi access authentication(I-D:
has been dropped from the agenda for todays meeting.

Logistics (Bluesheets, minutes takers: Charlie and Dirk, jabber:
Behcet, agenda bashing)

2. WG Status update   Chairs   5 Mins
   = ietf-netext-redirect-08 sent back for IPR issues
     related sections (5.4) were deleted.
   = ietf-netext-bulk-re-registration-04
       WC LC completed; significant changes made.  Need reviews.
          Carlos Bernardos volunteering to review.  Marco Liebsch
   = ietf-netext-pmip-lr-04
 WC LC completed; a few reviews received.
 Chair review done. Revised I-D needed.
   = ietf-netext-radius-pmip6-03
        WC LC completed; radius draft reviewed by radius expert Pete
McCann -
 he is happy with it. Only comment on collapse of
 ... (signalling?). Chair review submitted.  New revision awaited
 prior to forwarding the I-D to IESG
   = ietf-netext-logical-interface-support-02 Logical Interface:
     - set of issues have been identified, discussed at IETF 80
       - Editor has proposed text.
         - WG consensus needed, followed by revision


3. Open discussion of (remaining) issues related to logical interface
   support for multi-mode IP hosts              20 Mins
   We have had discussion on the set of issues that have been
   identified and captured in the tracker
   (http://trac.tools.ietf.org/wg/netext/trac/report/1) at
   IETF80. Authors have proposed text to resolve these issues. We need
   to close the issues and move forward. So we will seek consensus at
   the meeting and on the list in order to make progress.
   I-D: draft-ietf-netext-logical-interface-support-02


4. PMIP6 extensions for flow mobility  20 Mins
   This work item is stuck in a quagmire and has not made forward
   progress. There is no value in rehashing the same discussion as
   We will seek consensus for adoption of this I-D as WG document
   while recognizing that there are issues and concerns which need to
   be resolved. We will use the issue tracker to capture the issues
   and resolve them through the WG process. But we can do this only
   after we have a baseline document which is a WG adopted I-D.
   I-D: draft-bernardos-netext-pmipv6-flowmob-03

   = Proposal for making progress on flow mobility
     - draft-bernardos-netext-pmipv6-flowmob-03
       - there are concerns with that proposal
         - in order to make progress, recommend adopting it anyway
   Question to the attendees at the meeting: "Should we adopt I-D:
   draft-bernardos-netext-pmipv6-flowmob-03.txt as the starting point
   of the WG document?" 
   - strong consensus in room to adopt (18 to zero)


5. Prefix Delegation for Proxy Mobile IPv6    10 Mins
   I-D: draft-zhou-netext-pd-pmip-01
   URL: http://www.ietf.org/id/draft-zhou-netext-pd-pmip-01.txt
   Presenter: Carl Williams

   = Gap between NEMO and DHCPv6-PD (RFC 6276) in PMIPv6
   = In PMIPv6, prefix for MN is hosted on the access link --
     not a delegated prefix
     = For MR, need delegation (not specified).
       <note: applicable for home CPE case>
       = Prefix not properly "advertised" -- LMA could fail to
   = Carlos: Wants a bit more general solution to allow for MR <--> MAG
     as well as mobile MAG
     = Carl: looking at more limited problem with iPhone (e.g.,
   = Also 3GPP Rel-10 (TS 29.061) uses approach in RFC 6276
   = Key point: delegated prefix(es) need to be associated with
     PMIPv6 binding and forwarding state
     = Jari: struggling to understand the difference from other
     - With existing solutions, routers on path already have to know
     how to forward packets to delegated prefix
   == Behcet: problem is we do not have a PMIP "NEMO"
        == Jari rephrasing Jonne: in PMIP actually have a
           distributed router so LMA has to be explicitly told
     == Rajeev: MAG could have a /48, and when mobile attaches
        it gets a prefix from the /48.  When DHCP-PD is called, has
      to be allocated say, particular /56 from the /48.
     == Jonne: this seems like a clear solution.  Nodes
        behind the MR could use Mobile IP for their individual mobility if
  == Alex: more than two or three solutions around. Also stated that
   he may be aware of a potential IPR on this topic.
      So, the problem seems relevant.
  == Carl: Adopt as a Working Group document.

Chairs: how many people think the problem is relevant? 19(?)
How many have read it: 7
How many think that the proposed solution in the draft can be starting
point to work on the problem? In favor: 7 ;  Opposed: 1
Alex: could help on problem, but not comment on solution.


6. IP Traffic Offload Selector Option for Proxy Mobile IPv6   10 Mins
   Presenter: Sri Gundavelli/Jouni Korhonen

   - In PMIPv6: IPv4 home address to mobile node is anchored on home
     - All IP traffic from that IPv4 address is reverse tunneled to
     home net.
     - Operators are exploring new ways to offload some IP traffic.
     - Also important: the inverse capability (DON'T offload
     - IP Traffic Offload Selector Option used to match packets for
       = Uses RFC 6088
       - Filters: destination prefix, IP flow tuple, Application
 NAI/802.11 SSID, APN, Except-for
 - New option exchanged between MAG and LMA, using RFC 6088
   option formats (IPv4 binary traffic selector option)
   - Offload Policy Enforcement on MAG
      - Basavaraj: how about assigning a different address for
      traffic to be offloaded.
  = Basavaraj: What about NAT bindings?
  = Sri: but today MN can only get one address
  = Rajeev: There are ways to move the NAT binding
  = Jonne: How does MAG know what to offload
    == Sri: LMA tells MAG, according to filter
  = Bruno: What would trigger sending PBU with this option?
     == Sri: MAG could propose something
     == Rajeev: Could be proposed, and rejected...
  = Jonne: Hard to imagine how to populate the traffic
    filters with all the destination addresses
  = Liu Dapeng: How to tell about proximity of destination
    == Sri: it's about offloading the PDN-gw.

Rough working group consensus to adopt as WG item and draft.
11 people think we should solve the problem, 4 think we should not.
ML has to confirm adoption as starting WG doc


7. Access Network Information Option for Proxy Mobile IPv6   10 Mins
   Presenter: Jouni Korhonen
   - Need for LMA to offer differentiated services, charging, policing
     based on access network.
       = service treatment could depend on home/roaming, 802.11,
   - Proposal for new mobility option "ANI" MAG --> LMA
     = ANI == "Access Network Information"
       = Why not via AAA?  doable, but relies on external
   - New formats presented, showing Opertor Identifier option,
     Network identifier, etc.
     - Proposal to standardize the ANI option

Basavaraj : stay away from creating fixed options we don’t know yet
Charlie: is MAG responsible to transport it to LMA, MAG is operated by
  one operator, APs by different – network sharing (ID)
Alex: GSM, CDMA, …
Jouni: NAI
Alex: can we reuse?

5 have read the draft
4 think it is a relevant problem and we have to solve it
2 think it is no clear reason to carry more than ATT

Chairs: Please read documents and review them.
Chairs will poll the WG whether to work on this problem and adopt it
as WG item on the ML.