[netext] Netext WG minutes from IETF83

<Basavaraj.Patil@nokia.com> Sun, 08 April 2012 21:07 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31D721F855D for <netext@ietfa.amsl.com>; Sun, 8 Apr 2012 14:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi4klHbFxdDR for <netext@ietfa.amsl.com>; Sun, 8 Apr 2012 14:07:27 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B860421F854A for <netext@ietf.org>; Sun, 8 Apr 2012 14:07:26 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q38L7OXK001913 for <netext@ietf.org>; Mon, 9 Apr 2012 00:07:24 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 00:07:24 +0300
Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.136]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Sun, 8 Apr 2012 23:07:17 +0200
From: Basavaraj.Patil@nokia.com
To: netext@ietf.org
Thread-Topic: Netext WG minutes from IETF83
Thread-Index: AQHNFcuUK3sqJ4c1zk+SVaWl4cgTTQ==
Date: Sun, 08 Apr 2012 21:07:17 +0000
Message-ID: <CBA7667B.1D172%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [72.64.105.193]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5076D7CFE0FAC3438BCE43B92EBBAB3E@mgd.nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Apr 2012 21:07:24.0559 (UTC) FILETIME=[988DD9F0:01CD15CB]
X-Nokia-AV: Clean
Subject: [netext] Netext WG minutes from IETF83
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: Sun, 08 Apr 2012 21:07:29 -0000

Network-Based Mobility Extensions WG meeting at IETF83 (Paris, France)


WEDNESDAY, March 28, 2012
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. Juan-Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com)

Thanks also to the Meetecho team for providing remote access.

-------------------------------------------------------------

1. WG status update:
RFC 6463 published -- thanks to Jouni Korhonen for timely contribution and
responses

RFC Editor's queue:
  = radius-pmip6
  = bulk re-registration

IESG Discuss on pmip-lr (localized routing)

WGLC completed
  = netext-access-network-indicator options

-----------------------------------

2. Proxy Mobile IPv6 Extensions to Support Flow Mobility
I-D: draft-ietf-netext-pmipv6-flowmob		  CJ Bernardos

Enhancements for network-based flow mobility

Handoff Indicator (HI) allows MAG to indicate to the LMA that the same
prefixes should be assigned to mobile node

Cleanup of message format; lifetime=0 instead of C flag;
	no need for refresh (R) flag

New Security Considerations text

Marco Liebsch and Juan Carlos Zuniga volunteered to review the document

------------------------------------

3.  Prefix Delegation for Proxy Mobile IPv6		
I-D: draft-ietf-netext-pd-pmip			  Carl Williams

Mobile Router is a router whose mobility is managed by the network.
Since Taipei, text has been revised to avoid terminology issues.

Subsection to deal with deletion of delegated prefix.

New text in Security Considerations.

Raj: will do Chair review and start WGLC.

-------------------------------------

Chairs thanked Jari Arkko who has served as the Internet AD for 3
terms. 

--------------------------------------

5. PMIPv6 and Network Mobility Problem Statement	
I-D: draft-bernardos-netext-pmipv6-nemo-ps		CJ Bernardos

Idea example: move from a mobile device in airport to a bus and keep
	connectivity as the MAG's IP address moves through connectivity
	provided by higher-level MAGs.  MN keeps its IP address as
	it moves within the PMIPv6 domain.

Many questions...

Rajeev: What is new here?
CJB: to be explained in the next slides
Sri: so if the issue is that the service network changes. You need to
change the MAG address
CJB: that is solution space, but I agree that is a possibility
Jonne: The mobile MAG does not change address, so you don't need this
Gaetan: nested tunnels can be used, but no protocol change
Sri: you need to change the proxy
Laurent Thibault: this is nested tunneling
Gaetan: this is an implementation issue, but 5231 does not need changes

Carlos: However it is required to specify dual binding cache lookup.
Julien: Just the operational sequence of following the protocol...
Carlos: please post to the list how to make it work without protocol change

----------------------------------------

6. Quality of Service Option for Proxy Mobile IPv6	
I-D: draft-liebsch-netext-pmip6-qos 	      		M. Liebsch

nitial draft presented in Taipei

Updated draft contains details about:
= use cases
= protocol operation
= QoS option format
= ...

Exemplary Architecture
= LMA incorporated PCEF and uses Policy Control function
= cellular access MAG with access bearers
= 4 different classes of service
= e.g. 11e QoS  <---------> IP-based transport network non-cellular access
= new IP session PMIPv6 signaling {MAG/WLANC} <--> LMA

Raj: Diffserv for Transport Network, but today we don't specify anything
Laozi Bo: What is the nature of the QoS information to noncellular?
	Marco answer: code point
Marco: don't want to touch QoS policy on cellular network
Julien: 3GPP has put all the controls out of band even when using PMIP,
	but you are proposing to put it back in band
Rajeev: Is this a problem we need to solve in [netext]?
	recommend: look to see what signaling needs to happen between MAG/LMA
	We don't
Marco: QoS is something functional -- if don't have Gxa/Gxb, need something
Dow?: Forget about whether 3GPP exists.  Need inband signaling when
tunneling
	can overwrite QoS?
Julien: Is it necessary to do this with the mobility signaling?  Could it
be
	something else?
Raj: want to cut the line -- we just need to answer Julien's question
Rajeev: some merit if MAG can do rate limiting facing the wireless
Marco: more than DSC marking, also validation
Raj: advice -- simplify draft, don't worry about 3GPP, just make case for
	inband signaling.

-----------------------------------------------

7. PMIPv6 inter-working with WiFi access authentication		
I-D: draft-liebsch-netext-pmip6-authiwk		S. Gundavelli

Background: assume we know identity of mobile node
Raj: we have Radius extensions in RFC editor queue
Sri answer: fair comment, but we need to document how to use
Sri: just informational document, not really any new protocol
Alper: reasonable idea, maybe other SDOs should be doing this, please
	take Hotspot into consideration
Hui Deng: should say how the authentication work
Sri: for some things, should already know the IP address
Raj: Maybe web authentication should be done separately
Rajeev: the problem re webauth is what do we do with PBU/PBA signaling

RFC 5213 assumes completed authentication procedure before registration

WLAN is well-accepted access technology (HotSpot, ...)

Enable WLAN trusted access
	= eGPP recommendation for security and PMIP using non-3GPP radio
	  access

Document objective: specify AuthN interworking with PMIPv6
	= Include other SDOs deployment and recommendations
	= Include inter-working between WiFI AuthN and operators AAA
	= Considerations for related Web-authentication
Identification of protocol gaps and need for IETF specification

Juan-Carlos: what if better ways come up tomorrow

-------------------------------------------

8. Multiple APN Support for Trusted Wireless LAN Access	
I-D: draft-gundavelli-netext-multiple-apn-pmipv6    Hui Deng

= In SP WiFI arch with WLAN access network, MAG can establish PDN
  connection with APN at any time.  Limitation for multiple APN access
= IPv6 Prefix Coloring Approach

= Solution: MAG establishes PDN connection for default APN, IP
  address is assigned to the WLAN interface of UE over DHCP

= MN launches new applications; based on application triggers, MAG
  establishes new PDN connections to the indicated APN

= MAG creates APN specific connection, translation

= Example: MN new flows are established (flow coloring) when MAG
  sees new application launches.  Flows can go to different PDN-gw.

= Flow-based Source Address Selection.  MAG  creates Flow selector
  based on application.

= Data Path considerations

= Call Flow example (http needs to go to APN-2)

= Limitation: given APN hosting private DNS name space, DNS resolutions
	will fail
  == MAG might not have information for some application

= Question about charging issues?
  Answer: operator knows all about these assignments

= Jonne: Services from different ISPs works in similar way
	because operators know exactly where things are going
	It's harder dynamically, and some things might go the
	the wrong way.  Might start guessing what the user is
	doing, and might hinder the user from doing many things?
	= Are you proposing NAT for v6?  Ans: no, just for v4.

Raj: no protocol changes needed, so no work in [netext]
Sri: but every operator might do it a different way.

--------------------------------------------------

9. EAP Attributes  for WiFi - EPC Integration		
I-D: draft-valmikam-eap-attributes-wifi-epc-integration  R. Koodli

= Trusted WiFI emerging as a new access, but lacks some functions
	like APNs, Handover Indication, multiple APNs

= These are necessary to enable PMIP6 integration into mobile packet core

= defines new EAP attributes for existing EAP authentication [TS 33.402]

= One attribute: APN selection identifies APN
	== MN includes AT_VIRTUAL_NETWORK_ID in EAP Response

= Behcet: WiFi is a shared link, but PMIP works on point-to-point links
== Raj: out of scope for this discussion

= Use EAP fast re-auth, can be done any time.  MN includes
	AT_VIRTUAL_NETWORK_REQ in EAP Response/Identity of Fast Re-Auth
	Connect or disconnect does the "Handover Indicate"

Julien: Need to 802.1x re-authentication
Alper: Is there activity in IEEE to solve this at MAC layer?
	Don't want to pass arbitrary attributes over authentication protocols
	Raj: Ask Gabor, he goes to IEEE
Raj: will ask mailing list if we want to take this as a working group
document.

----------------------------------------------------

10. Service Selection for Mobile IPv6			
I-D: draft-korhonen-netext-rfc5149bis		Jouni Korhonen

RFC 5149 ought to be Standards Track

PMIP and 5149 have real deployments

RFC 5419bis:
- echo the Service Selection option back in PBa
- encode Service Selection using RFC 1035 domain name
- EPC uses Service Selection option as a BCE lookup key
- New failure code: MISSING OR UNKNOWN SERVICE
	versus previous SERVICE AUTHORIZATION FAILED
Sri: do not break interoperability
Raj: should adopt as WG document?
Hum: Strong consensus to adopt as WG document

Chairs will follow up on the mailing list