From liudapeng@chinamobile.com Wed Mar 28 02:14:54 2012 Return-Path: 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 C14DA21E8082; Wed, 28 Mar 2012 02:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.17 X-Spam-Level: ** X-Spam-Status: No, score=2.17 tagged_above=-999 required=5 tests=[AWL=1.495, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] 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 tz2Alh0k1mde; Wed, 28 Mar 2012 02:14:54 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B910B21E805A; Wed, 28 Mar 2012 02:14:53 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 6684CE5CD; Wed, 28 Mar 2012 17:14:52 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 4279AE5C6; Wed, 28 Mar 2012 17:14:52 +0800 (CST) Received: from MaxPassionPC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012032817145055-17853 ; Wed, 28 Mar 2012 17:14:50 +0800 From: "Dapeng Liu" To: References: <1332862493.5725.146.camel@acorde.it.uc3m.es> <00a001cd0cb8$160fea70$422fbf50$@chinamobile.com> <1332925320.5725.203.camel@acorde.it.uc3m.es> In-Reply-To: <1332925320.5725.203.camel@acorde.it.uc3m.es> Date: Wed, 28 Mar 2012 17:14:46 +0800 Message-ID: <007801cd0cc3$3b021280$b1063780$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJQkK46nyNBZ96T4q0wptmyEOjlGwFEnoe5AiV0sE+VXRKFUA== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-28 17:14:51, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-28 17:14:51, Serialize complete at 2012-03-28 17:14:51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18802.005 X-TM-AS-Result: No--23.255-7.0-31-10 X-imss-scan-details: No--23.255-7.0-31-10;No--23.255-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No X-Mailman-Approved-At: Mon, 02 Apr 2012 10:11:57 -0700 Cc: netext@ietf.org, dmm@ietf.org, 'Telemaco Melia' Subject: [netext] =?utf-8?b?562U5aSNOiBbRE1NXSDnrZTlpI06ICBOZXR3b3JrLWJh?= =?utf-8?q?sed_DMM_demo_=28Thu_15=3A30_room_251=29?= 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:14:54 -0000 Hi Carlos, -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm-bounces@ietf.org = [mailto:dmm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Carlos Jes=C3=BAs = Bernardos Cano =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B43=E6=9C=8828=E6=97=A5 = 17:02 =E6=94=B6=E4=BB=B6=E4=BA=BA: Dapeng Liu =E6=8A=84=E9=80=81: netext@ietf.org; dmm@ietf.org; 'Telemaco Melia' =E4=B8=BB=E9=A2=98: Re: [DMM] =E7=AD=94=E5=A4=8D: Network-based DMM demo = (Thu 15:30 room 251) Hi Dapeng, On Wed, 2012-03-28 at 15:54 +0800, Dapeng Liu wrote: > Hello Carlos, >=20 > Sounds interesting, may I ask how many virtual routers is running on=20 > the anchor router? Thanks. I'm not sure I got your question right. If you are asking how many = "virtual machines" we are running in our demo, then the answer is none, = we are using different physical boxes for each entity. If you are asking how many distributed logical interfaces are configured = on each anchor router, this depends on the mobility pattern of the MN, = but since we have one MN and three anchor routers, each of them can have = at most three. [Dapeng] Yeah, I am referring the 'distributed logical interfaces'. How about the = scalability? since it depends on the mobility pattern of MN.. Regards, -Dapeng Liu Thanks, Carlos >=20 > Regards, > -Dapeng Liu > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm-bounces@ietf.org = [mailto:dmm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Carlos Jes=C3=BA=20 > s Bernardos Cano > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2012=E5=B9=B43=E6=9C=8827=E6=97=A5 23:35 > =E6=94=B6=E4=BB=B6=E4=BA=BA: dmm@ietf.org; netext@ietf.org > =E6=8A=84=E9=80=81: Telemaco Melia > =E4=B8=BB=E9=A2=98: [DMM] Network-based DMM demo (Thu 15:30 room 251) >=20 > Hi all, >=20 > We'd like to announce that our network-based DMM demo will take place=20 > on Thursday at 15:30 in room 251. >=20 > The demo will show a Linux-based prototype based on [1] and [2]=20 > running on a live setup. >=20 > The setup is composed of three "anchor routers", a "centralized LMA"=20 > for control plane, a couple of correspondent nodes (a netbook and an=20 > IPv6 > camera) and a legacy IPv6 mobile node (a netbook). >=20 > Looking forward to seeing you there and getting your feedback. >=20 > Thanks, >=20 > Carlos, Telemaco and Juan Carlos >=20 > [1] http://tools.ietf.org/html/draft-bernardos-dmm-pmip-01 > [2] > http://tools.ietf.org/html/draft-bernardos-dmm-distributed-anchoring-0 > 0 > -- > Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG = FP:=20 > D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >=20 -- Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: = D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From Basavaraj.Patil@nokia.com Mon Apr 2 10:46:57 2012 Return-Path: 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 6647D21F8636 for ; Mon, 2 Apr 2012 10:46:57 -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 Id2vODzXqb5v for ; Mon, 2 Apr 2012 10:46:56 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10121F862A for ; Mon, 2 Apr 2012 10:46:56 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q32HklBs009049; Mon, 2 Apr 2012 20:46:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 20:46:46 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.48]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Mon, 2 Apr 2012 19:46:46 +0200 From: To: Thread-Topic: draft-ietf-netext-access-network-option review Thread-Index: AQHNEPiS4rEh4sywREWzcuYCDsgIsA== Date: Mon, 2 Apr 2012 17:46:45 +0000 Message-ID: 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: [172.19.59.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Apr 2012 17:46:46.0950 (UTC) FILETIME=[9319FC60:01CD10F8] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: [netext] draft-ietf-netext-access-network-option review 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:46:57 -0000 1. Rewrite the abstract. (I dislike an abstract that starts as "This specification...". One suggestion is to rephrase current text as follows: " The Local Mobility Agent in a Proxy Mobile IPv6 network is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached and/or the operator of that access network. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. " 2. s/In many architectures, such as Service Provider WIFI access aggregation architectures, or WLAN integrated mobile packet core architectures, there is a need for the local mobility anchor [RFC5213] to provide differentiated services and policing to the mobile nodes based on the access network to which they are attached./=20 Proxy mobile IPv6 (PMIPv6) [RFC5213] is considered as a solution for network based mobility in several types of network deployments. The architectures of networks such as Service provider WiFi access aggregation or, WLAN integrated mobile packet core are examples where PMIPv6 is a component of the overall architecture. Some of these architectures require the ability of the local mobility anchor (LMA) [RFC5213] to provide differentiated services and policing of traffic to the mobile nodes based on the access network to which they are attached. 3. I would recommend deleting the terms ANDSF and PCC from the terminology section. You have a reference to the 3GPP specs. Just leave it at that. 4. I would also like to see the I-D stating up front that these options are optional and not mandatory to the operation of PMIP6. There needs to be an applicability statement. 5. Given that you are including geo-location information as an option, the security consideration section needs to address privacy concerns. As an example, if the user of the mobile node has somehow indicated that his geo-location information should not be used, then the I-D needs a way of handling it. So I would suggest addressing the privacy issue as well in the security section. As soon as you have addressed these comments and submitted a revised I-D, I will forward it to the IESG. -Raj From Basavaraj.Patil@nokia.com Mon Apr 2 13:04:17 2012 Return-Path: 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 D717C21F85CE for ; Mon, 2 Apr 2012 13:04:17 -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 dEGnyF4eoZ6i for ; Mon, 2 Apr 2012 13:04:17 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id D7E7921F85C7 for ; Mon, 2 Apr 2012 13:04:16 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q32K4Erw024918; Mon, 2 Apr 2012 23:04:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 23:04:13 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.48]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Mon, 2 Apr 2012 22:04:13 +0200 From: To: Thread-Topic: Adopt I-D draft-korhonen-netext-rfc5149bis as Netext WG document? Thread-Index: AQHNEQvF2blscZIxjEWSCSFPRArsxw== Date: Mon, 2 Apr 2012 20:04:12 +0000 Message-ID: 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: [172.19.59.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Apr 2012 20:04:13.0874 (UTC) FILETIME=[C6A6B920:01CD110B] X-Nokia-AV: Clean Cc: draft-korhonen-netext-rfc5149bis@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Adopt I-D draft-korhonen-netext-rfc5149bis as Netext WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:04:18 -0000 Hello, At the Netext WG meeting at IETF83, the I-D Service Selection for Mobile IPv6 was discussed. We took a sense of the room to adopt the I-D as a working group document and there was a strong consensus to do so. Hence we are now asking the working group members over the mailing list regarding the adoption of this I-D as a Netext working group document. Please respond to the ML or the chairs if you are in favor of or against adopting this I-D as a WG document by April 16th, 2012. Question to WG members: Should we adopt draft-korhonen-netext-rfc5149bis-02.txt as a Netext WG document? Yes [ ] No [ ] -Chairs -------------------------------------------------------- Abstract In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents and local mobility agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This specification updates RFC5213 and obsoletes RFC5149. From Basavaraj.Patil@nokia.com Mon Apr 2 13:15:47 2012 Return-Path: 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 4A4F021F86C7 for ; Mon, 2 Apr 2012 13:15:47 -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 o6gaPK2RoDEy for ; Mon, 2 Apr 2012 13:15:46 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC0721F86BA for ; Mon, 2 Apr 2012 13:15:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q32KFDOc001905; Mon, 2 Apr 2012 23:15:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 23:15:36 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.48]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Mon, 2 Apr 2012 22:15:29 +0200 From: To: Thread-Topic: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: AQHNEQ1ZU4UsKDirLE6Xqr8rotLyqA== Date: Mon, 2 Apr 2012 20:15:29 +0000 Message-ID: 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: [172.19.59.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DDA45A286A8EB4E823406708318B6CA@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Apr 2012 20:15:36.0112 (UTC) FILETIME=[5D4BFB00:01CD110D] X-Nokia-AV: Clean Cc: draft-valmikam-eap-attributes-wifi-epc-integration@tools.ietf.org Subject: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:15:47 -0000 Hello, At IETF83 the WG discussed the I-D : draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes for WiFi - EPC Integration) This I-D proposes the use of EAP attributes as a means of signaling to the MAG by an MN the parameters such as: 1. Choice of APN 2. Handover indication 3. Multiple APN connectivity These attributes are relevant in the context of an MN connecting via a WiFi network to the 3GPP evolved packet core (EPC). The discussion in the WG favored using EAP attributes for parameters (1) and (2) above. The multiple APN connectivity problem is harder to solve.=20 Question to the WG members: Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as a Netext WG document with the intent of standardizing the following two attributes only : (1) Choice of APN and (2) Handover indication, to be carried in EAP signaling at the time of network access authentication? Please respond to the ML (or to me privately) if you favor the adoption of this I-D or are opposed to it. Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: Yes [ ] No [ ] -Basavaraj ---------------------------------------------------- Abstract With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. From sgundave@cisco.com Mon Apr 2 14:07:16 2012 Return-Path: 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 87DD721F8683 for ; Mon, 2 Apr 2012 14:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TCovNR7pg+cp for ; Mon, 2 Apr 2012 14:07:12 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5264521F8686 for ; Mon, 2 Apr 2012 14:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2922; q=dns/txt; s=iport; t=1333400829; x=1334610429; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=57uofegwdUM4yLU8d0ojoj+XWhgvQvA5mjspfxR/6uE=; b=BJRhtylu3uoPirySMPw1RfBTOCPUTN1mhSobqke18F4KY1Yk1r3u28nI 9XG1q1K32+pmIW9lYXfjzpEztzEkBlnac+Dx3JLA4nsiQAaYNqLO428Bg 64imHtUD3BJiGyVrn1FfS3oOhUhiAvi9V4FFtqgMt0iycwFtCFV43Pq19 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHz4eU+rRDoI/2dsb2JhbABFt3yBB4IJAQEBAwEBAQEPAScCATELBQ0BCBJbIg4CBA4FGweHYgQBC5tJnwsEjUqDJASIWI0JjkeBaIMH X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="38656774" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Apr 2012 21:07:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q32L78oR012466; Mon, 2 Apr 2012 21:07:08 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 14:07:08 -0700 Received: from 10.32.246.210 ([10.32.246.210]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Apr 2012 21:07:08 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 02 Apr 2012 14:07:07 -0700 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] draft-ietf-netext-access-network-option review Thread-Index: AQHNEPiS4rEh4sywREWzcuYCDsgIsJaIBy4v In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2012 21:07:08.0254 (UTC) FILETIME=[905B67E0:01CD1114] Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-access-network-option review 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 21:07:16 -0000 Raj: Thanks for the review. On 4/2/12 10:46 AM, "Basavaraj.Patil@nokia.com" wrote: > > 1. Rewrite the abstract. (I dislike an abstract that starts as "This > specification...". One suggestion is to rephrase current text as follows: ... OK > > " > The Local Mobility Agent in a Proxy Mobile IPv6 network is able to > provide access network and access operator specific handling or > policing of the mobile node traffic using information about the access > network to which the mobile node is attached and/or the operator of > that access network. This specification defines a mechanism and a > related mobility option for carrying the access network identifier and > the access operator identification information from the mobile access > gateway to the local mobility anchor over Proxy Mobile IPv6. > " OK > > 2. s/In many architectures, such as Service Provider WIFI access > aggregation architectures, or WLAN integrated mobile packet core > architectures, there is a need for the local mobility anchor > [RFC5213] to provide differentiated services and policing to the > mobile nodes based on the access network to which they are > attached./ > Proxy mobile IPv6 (PMIPv6) [RFC5213] is considered as a solution > for network based mobility in several types of network > deployments. The architectures of networks such as Service provider > WiFi access aggregation or, WLAN integrated mobile packet core are > examples where PMIPv6 is a component of the overall > architecture. Some of these architectures require the ability of > the local mobility anchor (LMA) [RFC5213] to provide differentiated > services and policing of traffic to the mobile nodes based on the > access network to which they are attached. > OK > 3. I would recommend deleting the terms ANDSF and PCC from the > terminology section. You have a reference to the 3GPP specs. Just > leave it at that. OK > > 4. I would also like to see the I-D stating up front that these > options are optional and not mandatory to the operation of > PMIP6. There needs to be an applicability statement. > OK > 5. Given that you are including geo-location information as an option, > the security consideration section needs to address privacy > concerns. As an example, if the user of the mobile node has somehow > indicated that his geo-location information should not be used, then > the I-D needs a way of handling it. So I would suggest addressing the > privacy issue as well in the security section. > Its already covered. > As soon as you have addressed these comments and submitted a revised > I-D, I will forward it to the IESG. > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Apr 2 15:27:49 2012 Return-Path: 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 54A6D21F8747 for ; Mon, 2 Apr 2012 15:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OhDWY3kAFmTS for ; Mon, 2 Apr 2012 15:27:48 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9463821F8737 for ; Mon, 2 Apr 2012 15:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2266; q=dns/txt; s=iport; t=1333405668; x=1334615268; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Hg63fZOX6knM/skgZ8Q1D0xfx3+lQuxGNeA4E34eDIA=; b=l0tBWY20Sk8s0WaGPvKslXl6UosolXt7Z203U8PTFPnAizkzasS8lbXy 5DFwLeqi+VxB1QCvnARjMuDK2mhA5cI8N4b+b3LxLZ+1LMPvau8dqyQtY DFKkkGOYNLHBJvRUOQiQ+Cj/IOlfjF6nHTx9/gJUpPATHsL7jaFlz6WkX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKknek+rRDoH/2dsb2JhbAA6CbgMgQeCCQEBAQMBAQEBDwEnAgExCxIBCCVIMAIEAQ0FIodiBAygIZcrBIsHhWcEiFiNCY5HgWiDBw X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="36180975" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 22:27:48 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32MRmRv029028; Mon, 2 Apr 2012 22:27:48 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 15:27:48 -0700 Received: from 10.32.246.210 ([10.32.246.210]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Apr 2012 22:27:48 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 02 Apr 2012 15:27:47 -0700 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] Adopt I-D draft-korhonen-netext-rfc5149bis as Netext WG document? Thread-Index: AQHNEQvF2blscZIxjEWSCSFPRArsx5aIHZGZ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2012 22:27:48.0196 (UTC) FILETIME=[D52FF240:01CD111F] Cc: draft-korhonen-netext-rfc5149bis@tools.ietf.org, netext-chairs@tools.ietf.org Subject: Re: [netext] Adopt I-D draft-korhonen-netext-rfc5149bis as Netext WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 22:27:49 -0000 Yes. This update is needed. One thing me must make sure - This option is already specified in 3GPP specs and there are implementations that use this option. We must ensure backward compatibility; the bis-draft should not result in breaking existing implementations, or significant spec updates. Sri On 4/2/12 1:04 PM, "Basavaraj.Patil@nokia.com" wrote: > > Hello, > > At the Netext WG meeting at IETF83, the I-D Service Selection for > Mobile IPv6 was > discussed. We took a sense of the room to adopt the I-D as a working > group document and there was a strong consensus to do so. > Hence we are now asking the working group members over the mailing > list regarding the adoption of this I-D as a Netext working group document. > Please respond to the ML or the chairs if you are in favor of or > against adopting this I-D as a WG document by April 16th, 2012. > > Question to WG members: > Should we adopt draft-korhonen-netext-rfc5149bis-02.txt as a Netext WG > document? > > Yes [ ] > > No [ ] > > -Chairs > > -------------------------------------------------------- > > Abstract > > In some Mobile IPv6 deployments, identifying the mobile node or the > mobility service subscriber is not enough to distinguish between > multiple services possibly provisioned to the said mobile node and > its mobility service subscription. A capability to specify different > services in addition to the mobile node identity can be leveraged to > provide flexibility for mobility service providers on provisioning > multiple services to one mobility service subscription. This > document describes a Service Selection Mobility Option for both > conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to > assist home agents and local mobility agents to make a specific > service selection for the mobility service subscription during the > binding registration procedure. This specification updates RFC5213 > and obsoletes RFC5149. > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jouni.nospam@gmail.com Tue Apr 3 00:17:55 2012 Return-Path: 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 8319921F8483 for ; Tue, 3 Apr 2012 00:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 WhLID27t2dPK for ; Tue, 3 Apr 2012 00:17:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08F0D21F847F for ; Tue, 3 Apr 2012 00:17:54 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3158304obb.31 for ; Tue, 03 Apr 2012 00:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zOvp54/KVkaNwggoUvMSl2OVHncmsZC8J60/JxpGsi8=; b=fZmif/M4Hp4/xzHUqwpWYycym3Vem9gmF/4YBjtXS2FtYVEXhhcKR9qOIXmtfiby0V gFejWptYz4BQryGTdDWgBw/qJJXUgaXvtMlbQcqwjPDCdxw+si1Cd+Tlj325jj/WGC9m lSbUH/LFjO/PM0eMPWrYvHiAb64OMnNYBOBt29j8W+3JZd1Ni3HrOvccsnKR+J0Mxe5l 1uWFdVO/K5Z9ZbskzCgVwN60DV4p9rKUHSGB7P7oJNdNIUw/M/QJ9i9A0c4F0lu6bk8D vvsA26uXR8bPiYZlkiLEuGbMg/WBBm55USaGlQaBjgk5aVErPldAsIauojt5avG/xq2r ufKg== Received: by 10.60.169.146 with SMTP id ae18mr17174343oec.36.1333437474591; Tue, 03 Apr 2012 00:17:54 -0700 (PDT) Received: from [10.255.135.226] ([192.100.123.77]) by mx.google.com with ESMTPS id k7sm16343107oei.0.2012.04.03.00.17.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 00:17:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 3 Apr 2012 10:17:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5C8C59-85AA-4AE4-92A7-CF4B62399283@gmail.com> References: To: X-Mailer: Apple Mail (2.1084) Cc: draft-korhonen-netext-rfc5149bis@tools.ietf.org, netext@ietf.org, netext-chairs@tools.ietf.org Subject: Re: [netext] Adopt I-D draft-korhonen-netext-rfc5149bis as Netext WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 07:17:55 -0000 Yes [X] One thing to point out. There are implementations and deployments out there. Therefore ensuring we do not break backward compatibility with those is of high importance. - Jouni On Apr 2, 2012, at 11:04 PM, = wrote: >=20 > Hello, >=20 > At the Netext WG meeting at IETF83, the I-D Service Selection for > Mobile IPv6 was > discussed. We took a sense of the room to adopt the I-D as a working > group document and there was a strong consensus to do so. > Hence we are now asking the working group members over the mailing > list regarding the adoption of this I-D as a Netext working group = document. > Please respond to the ML or the chairs if you are in favor of or > against adopting this I-D as a WG document by April 16th, 2012. >=20 > Question to WG members: > Should we adopt draft-korhonen-netext-rfc5149bis-02.txt as a Netext WG > document? >=20 > Yes [ ] >=20 > No [ ] >=20 > -Chairs >=20 > -------------------------------------------------------- >=20 > Abstract >=20 > In some Mobile IPv6 deployments, identifying the mobile node or the > mobility service subscriber is not enough to distinguish between > multiple services possibly provisioned to the said mobile node and > its mobility service subscription. A capability to specify = different > services in addition to the mobile node identity can be leveraged to > provide flexibility for mobility service providers on provisioning > multiple services to one mobility service subscription. This > document describes a Service Selection Mobility Option for both > conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to > assist home agents and local mobility agents to make a specific > service selection for the mobility service subscription during the > binding registration procedure. This specification updates RFC5213 > and obsoletes RFC5149. >=20 >=20 From rkoodli@cisco.com Tue Apr 3 13:13:20 2012 Return-Path: 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 7763A11E81C6 for ; Tue, 3 Apr 2012 13:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ZOwpPH51egN1 for ; Tue, 3 Apr 2012 13:13:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D643911E81C3 for ; Tue, 3 Apr 2012 13:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=2556; q=dns/txt; s=iport; t=1333484000; x=1334693600; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=yrpP4CY68cmHQWwIkpStk2c0Q6lA0vOB42Jk7lBdqVw=; b=aMpXixVgO4/mFmiaJO7VDB/WIThT1Q+C4yIMxOIRk608x8URnB0skdI4 pPcDYS0zxfI5ofy513rMkTbc4uVZw5aXJ8wL2XnPFQuFRCiV23lG394Hx EM5lHWnSjrbgpg43XEkR5Li9rLNxceZv3foFt7Dy8c5OKwZFRsoNgIDDc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKpZe0+tJXHA/2dsb2JhbABFuBWBB4IJAQEBAwEBAQEPAScCASoHCwUNAQhtMAIEAQ0FIodiBQubMZ52BJBmBIhYjQuOR4Fpgwc X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71812239" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 03 Apr 2012 20:13:16 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q33KDGo3007324; Tue, 3 Apr 2012 20:13:16 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:13:16 -0500 Received: from 10.21.82.216 ([10.21.82.216]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 20:13:15 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 03 Apr 2012 13:17:19 -0700 From: Rajeev Koodli To: "Basavaraj.Patil@nokia.com" , Message-ID: Thread-Topic: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: AQHNEQ1ZU4UsKDirLE6Xqr8rotLyqJaJi2+0 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 20:13:16.0300 (UTC) FILETIME=[34601CC0:01CD11D6] Cc: draft-valmikam-eap-attributes-wifi-epc-integration@tools.ietf.org Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:13:20 -0000 Yes [X] There is a need to provide the APN and Handover Indication from a MN. The ID specifies EAP attributes which are used in the required EAP-AKA' authentication procedure. Thanks. -Rajeev On 4/2/12 1:15 PM, "Basavaraj.Patil@nokia.com" wrote: > > Hello, > > At IETF83 the WG discussed the I-D : > draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes > for WiFi - EPC Integration) > > This I-D proposes the use of EAP attributes as a means of signaling to > the MAG by an MN the parameters such as: > 1. Choice of APN > 2. Handover indication > 3. Multiple APN connectivity > > These attributes are relevant in the context of an MN connecting via a > WiFi network to the 3GPP evolved packet core (EPC). > > The discussion in the WG favored using EAP attributes for parameters > (1) and (2) above. The multiple APN connectivity problem is harder to > solve. > > Question to the WG members: > Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration > as a Netext WG document with the intent of standardizing the following > two attributes only : (1) Choice of APN and (2) Handover indication, to be > carried in EAP signaling at the time of network access authentication? > > Please respond to the ML (or to me privately) if you favor the adoption > of this I-D or are opposed to it. > > Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: > > Yes [ ] > > No [ ] > > -Basavaraj > > ---------------------------------------------------- > > Abstract > > With WiFi beginning to establishing itself as a trusted access > network for service providers, it has become important to provide > functions commonly available in 3G and 4G networks in WiFi access > networks. Such functions include Access Point Name (APN) Selection, > multiple Packet Data Network (PDN) connections and seamless mobility > between WiFi and 3G/4G networks. > > EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access > authentication protocol for trusted access networks. This IETF > specification is required for mobile devices to access the 3GPP > Evolved Packet Core (EPC) networks. This document defines a few new > EAP attributes and procedures to provide the above-mentioned > functions in trusted WiFi access networks. > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Tue Apr 3 13:22:01 2012 Return-Path: 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 6E2B011E81D8 for ; Tue, 3 Apr 2012 13:22:01 -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 TWocWhk00kWN for ; Tue, 3 Apr 2012 13:22:00 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 965D311E81D2 for ; Tue, 3 Apr 2012 13:21:59 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q33KLsS2016852; Tue, 3 Apr 2012 23:21:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 23:21:54 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.33]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Tue, 3 Apr 2012 22:21:53 +0200 From: To: , Thread-Topic: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: AQHNEQ1ZU4UsKDirLE6Xqr8rotLyqJaJi2+0//+L/QA= Date: Tue, 3 Apr 2012 20:21:52 +0000 Message-ID: In-Reply-To: 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: [172.19.59.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Apr 2012 20:21:54.0216 (UTC) FILETIME=[6913D280:01CD11D7] X-Nokia-AV: Clean Cc: draft-valmikam-eap-attributes-wifi-epc-integration@tools.ietf.org Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:22:01 -0000 Are these attributes (APN and HO indication) applicable to any EAP method? Or these attributes specific to only EAP-AKA'? -Raj On 4/3/12 3:17 PM, "ext Rajeev Koodli" wrote: > >Yes [X] > >There is a need to provide the APN and Handover Indication from a MN. >The ID specifies EAP attributes which are used in the required EAP-AKA' >authentication procedure. > >Thanks. > >-Rajeev > > > > >On 4/2/12 1:15 PM, "Basavaraj.Patil@nokia.com" >wrote: > >>=20 >> Hello, >>=20 >> At IETF83 the WG discussed the I-D : >> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >> for WiFi - EPC Integration) >>=20 >> This I-D proposes the use of EAP attributes as a means of signaling to >> the MAG by an MN the parameters such as: >> 1. Choice of APN >> 2. Handover indication >> 3. Multiple APN connectivity >>=20 >> These attributes are relevant in the context of an MN connecting via a >> WiFi network to the 3GPP evolved packet core (EPC). >>=20 >> The discussion in the WG favored using EAP attributes for parameters >> (1) and (2) above. The multiple APN connectivity problem is harder to >> solve.=20 >>=20 >> Question to the WG members: >> Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration >> as a Netext WG document with the intent of standardizing the following >> two attributes only : (1) Choice of APN and (2) Handover indication, to >>be >> carried in EAP signaling at the time of network access authentication? >>=20 >> Please respond to the ML (or to me privately) if you favor the adoption >> of this I-D or are opposed to it. >>=20 >> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>=20 >> Yes [ ] >>=20 >> No [ ] >>=20 >> -Basavaraj >>=20 >> ---------------------------------------------------- >>=20 >> Abstract >>=20 >> With WiFi beginning to establishing itself as a trusted access >> network for service providers, it has become important to provide >> functions commonly available in 3G and 4G networks in WiFi access >> networks. Such functions include Access Point Name (APN) Selection, >> multiple Packet Data Network (PDN) connections and seamless mobility >> between WiFi and 3G/4G networks. >>=20 >> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >> authentication protocol for trusted access networks. This IETF >> specification is required for mobile devices to access the 3GPP >> Evolved Packet Core (EPC) networks. This document defines a few new >> EAP attributes and procedures to provide the above-mentioned >> functions in trusted WiFi access networks. >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From sarikaya2012@gmail.com Wed Apr 4 08:36:41 2012 Return-Path: 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 E36C821F85AA; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gs9PE1uZOnR2; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0421F859A; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) Received: by iazz13 with SMTP id z13so596447iaz.31 for ; Wed, 04 Apr 2012 08:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=0IFHs7OmCVojInDug3WkMb1WhOQO6LcSt1FccI8v8WM=; b=ZtGzpL97wafhTgK7TgxNeafQaQWMC8Fd1jslNFzqc1sjmK6tDKcbMp+G4ah4cm85+/ A5IEbZG2GW9doGIukrio1pvu8rCvve8/kUs1+McxTPDHr5iAignkaqJsJJZLipErpRn2 RVVoqJVDXT0k4kv7lzfANvO2Dw7KUe+kDetTpFQ7x8J27G8huJPvLXt7F4tec7WF8E20 /3ZTHMXzqevehKm1RsWuXKfOFVYU3M9mWghwtn9qhAYC0jCY+yvrkpn1/EEItI3ESM5H ABHR44rDzxAbl9QLOKJNFhfoXOSBRDm0gJSdZp8S0ZUjFcCMPH02JiOHq+y/+RJ6YOhq ZoxQ== MIME-Version: 1.0 Received: by 10.50.222.131 with SMTP id qm3mr2023195igc.66.1333553800886; Wed, 04 Apr 2012 08:36:40 -0700 (PDT) Received: by 10.231.8.99 with HTTP; Wed, 4 Apr 2012 08:36:40 -0700 (PDT) Date: Wed, 4 Apr 2012 10:36:40 -0500 Message-ID: From: Behcet Sarikaya To: Internet Area , v6ops@ietf.org, Softwires-wg , netext@ietf.org, dmm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] Announcing fmc mailing list X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 04 Apr 2012 15:36:42 -0000 A new list has been created for fixed mobile convergence (FMC) discussions, fmc@ietf.org. If interested, please subscribe the list using this link: https://www.ietf.org/mailman/listinfo/fmc Regards, Behcet & Dirk From Basavaraj.Patil@nokia.com Sun Apr 8 14:07:28 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: To: Thread-Topic: Netext WG minutes from IETF83 Thread-Index: AQHNFcuUK3sqJ4c1zk+SVaWl4cgTTQ== Date: Sun, 8 Apr 2012 21:07:17 +0000 Message-ID: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: =3D radius-pmip6 =3D bulk re-registration IESG Discuss on pmip-lr (localized routing) WGLC completed =3D 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=3D0 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 =09 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.=20 -------------------------------------- 5. PMIPv6 and Network Mobility Problem Statement=09 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=09 I-D: draft-liebsch-netext-pmip6-qos M. Liebsch nitial draft presented in Taipei Updated draft contains details about: =3D use cases =3D protocol operation =3D QoS option format =3D ... Exemplary Architecture =3D LMA incorporated PCEF and uses Policy Control function =3D cellular access MAG with access bearers =3D 4 different classes of service =3D e.g. 11e QoS <---------> IP-based transport network non-cellular acces= s =3D 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 =09 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 =3D eGPP recommendation for security and PMIP using non-3GPP radio access Document objective: specify AuthN interworking with PMIPv6 =3D Include other SDOs deployment and recommendations =3D Include inter-working between WiFI AuthN and operators AAA =3D 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=09 I-D: draft-gundavelli-netext-multiple-apn-pmipv6 Hui Deng =3D In SP WiFI arch with WLAN access network, MAG can establish PDN connection with APN at any time. Limitation for multiple APN access =3D IPv6 Prefix Coloring Approach =3D Solution: MAG establishes PDN connection for default APN, IP address is assigned to the WLAN interface of UE over DHCP =3D MN launches new applications; based on application triggers, MAG establishes new PDN connections to the indicated APN =3D MAG creates APN specific connection, translation =3D Example: MN new flows are established (flow coloring) when MAG sees new application launches. Flows can go to different PDN-gw. =3D Flow-based Source Address Selection. MAG creates Flow selector based on application. =3D Data Path considerations =3D Call Flow example (http needs to go to APN-2) =3D Limitation: given APN hosting private DNS name space, DNS resolutions will fail =3D=3D MAG might not have information for some application =3D Question about charging issues? Answer: operator knows all about these assignments =3D 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? =3D 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 =09 I-D: draft-valmikam-eap-attributes-wifi-epc-integration R. Koodli =3D Trusted WiFI emerging as a new access, but lacks some functions like APNs, Handover Indication, multiple APNs =3D These are necessary to enable PMIP6 integration into mobile packet core =3D defines new EAP attributes for existing EAP authentication [TS 33.402] =3D One attribute: APN selection identifies APN =3D=3D MN includes AT_VIRTUAL_NETWORK_ID in EAP Response =3D Behcet: WiFi is a shared link, but PMIP works on point-to-point links =3D=3D Raj: out of scope for this discussion =3D 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 =09 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 From internet-drafts@ietf.org Sat Apr 14 07:08:49 2012 Return-Path: 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 289A721F85C9; Sat, 14 Apr 2012 07:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AQWiECkRGZob; Sat, 14 Apr 2012 07:08:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F8A21F85A3; Sat, 14 Apr 2012 07:08:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120414140848.1247.85601.idtracker@ietfa.amsl.com> Date: Sat, 14 Apr 2012 07:08:48 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-08.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 14:08:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-08.txt Pages : 17 Date : 2012-04-14 The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 08.txt From jouni.nospam@gmail.com Mon Apr 16 03:58:39 2012 Return-Path: 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 A2C4921F873E for ; Mon, 16 Apr 2012 03:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] 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 M-c4lQlUV5QO for ; Mon, 16 Apr 2012 03:58:38 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4BF21F86FA for ; Mon, 16 Apr 2012 03:58:38 -0700 (PDT) Received: by eeke51 with SMTP id e51so1309033eek.31 for ; Mon, 16 Apr 2012 03:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=uGoAi0dwZsg8r9zcxqZaRLIDF6CE40QiO1PkgUZg1sY=; b=tjXIv+0vpRcsLWBv85iz9j/IGfyBNnuxdBbMa097r2VJE9Gqwcya5nzzQHBBALDPvA bADTm8ZI4zZXQsKe0KC6k5JL/0geRU76aCeEc6uDRY2Y6FikssEKWe3ad9lqwhgbqnzC Q7MFbm4BjbY/kk1mnDpTcKrfwgrTSjYitsUgqSz+7oLlXLtHto9edIeTcxnAMpq8LxAA BJvHeRm0igFN2FTjpNLOhcvQQCtGHz3PB2924z7qaBHFFM5XZdm7iKofCokN4MouwteM H5jc0lR8Jv3cqhUVvf3oVn75BkGfckg7dzi3VWOTSTbOeC26Q2WxNyoVuwfdXHrC7Tbn TA2g== Received: by 10.213.10.67 with SMTP id o3mr828636ebo.177.1334573917291; Mon, 16 Apr 2012 03:58:37 -0700 (PDT) Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id d54sm85447929eei.9.2012.04.16.03.58.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 03:58:36 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Apr 2012 13:58:34 +0300 Message-Id: To: netext@ietf.org, Brian Haberman Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-netext-radius-pmip6@tools.ietf.org Subject: [netext] Default gateway attributes in to-be-rfc6572 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:58:39 -0000 Folks, Following the "tradition" we are back in WG asking for few more things for ietf-draft-netext-radius-pmip6 ;) The I-D was already in AUTH48, so this is not a shopping list for all kinds of things but.. Since RFC5844 has a mobility option for the IPv4 default gateway and the I-D & RFC5844 allow for signaling an IPv4 subnet instead of just /32 it came apparent that we cannot assume all MAGs/LMAs could figure out the default gateway address algorithmically for all deployments. The assumption had been till AUTH48 phase that the default gateway would just be the network_address+1 (and something else in case of RFC3021 /31). However, this should be a deployment choice, not based on an assumption that everybody will comply with network_address+1. Therefore, we need two new attributes to explicitly state which is the IPv4 default gateway address that has to be populated into PMIPv6 signaling. Along with the addition of two new attributes, we also should fix few other things that are seemingly not-too-right. Sorry for a lengthy mail but there are several (trivial) changes all around the document. The proposed new text follows and quick comments are solicited: 4.20. PMIP6-Home-IPv4-Gateway [RFC5844] specifies extensions to Proxy Mobile IPv6 protocol which enable IPv4 home address mobility support to the MN. The PMIP6-Home- IPv4-Gateway attribute (Type value TBD1) is of type Address and contains the default gateway IPv4 address for the MN. This address is populated into the PMIPv6 IPv4 Default-Router Address Option [RFC5844]. The address MUST belong to the subnet defined in the PMIP6-Home-IPv4-HoA attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Home IPv4 default gateway +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Home-IPv4-Gateway TBD1. Length: = 6 octets Home IPv4 default gateway address: This field is of type Address and contains a 4-octet IPv4 default gateway address. 4.21. PMIP6-Visited-IPv4-Gateway [RFC5844] specifies extensions to Proxy Mobile IPv6 protocol which enable IPv4 home address mobility support to the MN. The PMIP6- Visited-IPv4-Gateway attribute (Type value TBD2) is of type Address and contains the default gateway IPv4 address for the MN. This address is populated into the PMIPv6 IPv4 Default-Router Address Option [RFC5844]. The address MUST belong to the subnet defined in the PMIP6-Visited-IPv4-HoA attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Visited IPv4 default gateway +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PMIP6-Visited-IPv4-Gateway TBD2. Length: = 6 octets Visited IPv4 default gateway address: This field is of type Address and contains a 4-octet IPv4 default gateway address. 5.2. Table of Attributes The following table provides a guide to attributes that may be found in authentication and authorization RADIUS messages between the MAG and the AAA server. Request Accept Reject Challenge # Attribute 1 0-1 0 0 1 User-Name 0-1 0 0 0 4 NAS-IP-Address 0-1 0-1 0 0 5 NAS-Port 0-1 0-1 0 0 6 Service-Type 0-1 0-1 0 0-1 24 State 0 0-1 0 0 25 Class 0 0-1 0 0-1 27 Session-Timeout 0-1 0 0 0 31 Calling-Station-Id 0-1 0 0 0 32 NAS-Identifier 0+ 0+ 0+ 0+ 33 Proxy-State 0-1 0 0 0 69 NAS-Port-Type 0+ 0+ 0+ 0+ 79 EAP-Message 1 1 1 1 80 Message-Authenticator 0-1 0-1 0 0 89 Chargeable-User-Identity 0-1 0 0 0 95 NAS-IPv6-Address 0-1 0-1 0 0 124 MIP6-Feature-Vector 0 1 0 0 145 Mobile-Node-Identifier 0-1 0-1 0 0 146 Service-Selection 0 0-1 0 0 147 PMIP6-Home-LMA-IPv6-Address 0-1 0-1 0 0 148 PMIP6-Visited-LMA-IPv6-Address 0 0-1 0 0 149 PMIP6-Home-LMA-IPv4-Address 0-1 0-1 0 0 150 PMIP6-Visited-LMA-IPv4-Address 0 0+ 0 0 151 PMIP6-Home-HN-Prefix 0 0+ 0 0 152 PMIP6-Visited-HN-Prefix 0 0-1 0 0 153 PMIP6-Home-Interface-ID 0 0-1 0 0 154 PMIP6-Visited-Interface-ID 0 0-1 0 0 155 PMIP6-Home-IPv4-HoA 0 0-1 0 0 156 PMIP6-Visited-IPv4-HoA 0 0-1 0 0 157 PMIP6-Home-DHCP4-Server-Address 0 0-1 0 0 158 PMIP6-Visited-DHCP4-Server-Address 0 0-1 0 0 159 PMIP6-Home-DHCP6-Server-Address 0 0-1 0 0 160 PMIP6-Visited-DHCP6-Server-Address 0 0-1 0 0 TBD1 PMIP6-Home-IPv4-Gateway 0 0-1 0 0 TBD2 PMIP6-Visited-IPv4-Gateway 6.2. Table of Attributes The following table provides a guide to which attributes may be found in authorization process between LMA and the AAA. Request Accept Reject Challenge # Attribute 1 0-1 0 0 1 User-Name 0-1 0-1 0 0 4 NAS-IP-Address 0-1 0-1 0 0 5 NAS-Port 1 0-1 0 0 6 Service-Type 0 0-1 0 0 25 Class 0 0-1 0 0-1 27 Session-Timeout 0-1 0 0 0 31 Calling-Station-Id 1 0 0 0 32 NAS-Identifier 0+ 0+ 0+ 0+ 33 Proxy-State 1 0 0 0 69 NAS-Port-Type 1 1 1 1 80 Message-Authenticator 0-1 0-1 0 0 89 Chargeable-User-Identity 0-1 0-1 0 0 95 NAS-IPv6-Address 0-1 0-1 0 0 124 MIP6-Feature-Vector 1 0 0 0 145 Mobile-Node-Identifier 0-1 0-1 0 0 146 Service-Selection 0-1 0 0 0 147 PMIP6-Home-LMA-IPv6-Address 0-1 0 0 0 148 PMIP6-Visited-LMA-IPv6-Address 0-1 0 0 0 149 PMIP6-Home-LMA-IPv4-Address 0-1 0 0 0 150 PMIP6-Visited-LMA-IPv4-Address 0+ 0+ 0 0 151 PMIP6-Home-HN-Prefix 0+ 0+ 0 0 152 PMIP6-Visited-HN-Prefix 0-1 0-1 0 0 153 PMIP6-Home-Interface-ID 0-1 0-1 0 0 154 PMIP6-Visited-Interface-ID 0-1 0-1 0 0 155 PMIP6-Home-IPv4-HoA 0-1 0-1 0 0 156 PMIP6-Visited-IPv4-HoA 0-1 0-1 0 0 TBD1 PMIP6-Home-IPv4-Gateway 0-1 0-1 0 0 TBD2 PMIP6-Visited-IPv4-Gateway 7.3. Table of Attributes The following table provides a list of attributes that may be included in the RADIUS Accounting messages. These attributes are to complement the set of accounting attributes already required by [RFC2866] and [RFC2869]. Accounting Request # Attribute 0-1 145 Mobile-Node-Identifier 0-1 146 Service-Selection 0-1 147 PMIP6-Home-LMA-IPv6-Address 0-1 148 PMIP6-Visited-LMA-IPv6-Address 0-1 149 PMIP6-Home-LMA-IPv4-Address 0-1 150 PMIP6-Visited-LMA-IPv4-Address 0+ 151 PMIP6-Home-HN-Prefix 0+ 152 PMIP6-Visited-HN-Prefix 0-1 155 PMIP6-Home-IPv4-HoA 0-1 156 PMIP6-Visited-IPv4-HoA 0-1 31 Calling-Station-Id 0-1 80 Message-Authenticator 0-1 89 Chargeable-User-Identity 0-1 124 MIP6-Feature-Vector 9.1. Attribute Type Codes This specification defines the following new RADIUS attribute type values: Mobile-Node-Identifier 145 Service-Selection 146 PMIP6-Home-LMA-IPv6-Address 147 PMIP6-Visited-LMA-IPv6-Address 148 PMIP6-Home-LMA-IPv4-Address 149 PMIP6-Visited-LMA-IPv4-Address 150 PMIP6-Home-HN-Prefix 151 PMIP6-Visited-HN-Prefix 152 PMIP6-Home-Interface-ID 153 PMIP6-Visited-Interface-ID 154 PMIP6-Home-IPv4-HoA 155 PMIP6-Visited-IPv4-HoA 156 PMIP6-Home-DHCP4-Server-Address 157 PMIP6-Visited-DHCP4-Server-Address 158 PMIP6-Home-DHCP6-Server-Address 159 PMIP6-Visited-DHCP6-Server-Address 160 PMIP6-Home-IPv4-Gateway TBD1 PMIP6-Visited-IPv4-Gateway TBD2 Last.. a question to the WG. Currently in the I-D we have a restriction that PMIP6-Visited-LMA-*-Address can only be added by the VAAA. Obviously the assumption is that the VAAA belongs to a different administrative domain than the HAAA. Is there a need to have this kind of limitation? Meaning, should the HAAA be allowed for including the PMIP6-Visited-LMA-*-Address attribute as well? If you think it should, explain why and which scenario it should apply? - Jouni (on behalf of the to-be-rfc6572 authors) From Basavaraj.Patil@nokia.com Tue Apr 17 12:52:47 2012 Return-Path: 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 D2C0D11E80D9 for ; Tue, 17 Apr 2012 12:52:47 -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=[AWL=0.000, 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 6zeBcki60lvB for ; Tue, 17 Apr 2012 12:52:42 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6E33811E80D1 for ; Tue, 17 Apr 2012 12:52:39 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3HJqWA8028025 for ; Tue, 17 Apr 2012 22:52:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 22:52:34 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.136]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Tue, 17 Apr 2012 21:52:34 +0200 From: To: Thread-Topic: Consensus call to add additional attributes to I-D: draft-ietf-netext-radius-pmip6 Thread-Index: AQHNHNOhz5j3l5kuSEqUom7LbBnFtw== Date: Tue, 17 Apr 2012 19:52:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FA491D3D7CBB24D9E68EBE4E9CF1E5D@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2012 19:52:34.0223 (UTC) FILETIME=[A1D2B3F0:01CD1CD3] X-Nokia-AV: Clean Subject: [netext] Consensus call to add additional attributes to I-D: draft-ietf-netext-radius-pmip6 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:52:48 -0000 Hello, Authors of I-D: RADIUS Support for Proxy Mobile IPv6 have discovered a couple of missing attributes as well as minor fixes to the I-D. Please see the details of the attributes and revised text in the email sent to the ML earlier at: http://www.ietf.org/mail-archive/web/netext/current/msg02396.html We would like to get review and feedback on the proposed attributes and text from WG members. Hence consider this as a consensus call to adopt the text proposed in the email (see link above). The deadline for receiving comments is : April 30th. -Chairs From Basavaraj.Patil@nokia.com Thu Apr 19 17:00:15 2012 Return-Path: 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 385B811E80CB; Thu, 19 Apr 2012 17:00:15 -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 b+LZVXrZnC0v; Thu, 19 Apr 2012 17:00:14 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1A03F11E8073; Thu, 19 Apr 2012 17:00:13 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3K0066s020612; Fri, 20 Apr 2012 03:00:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Apr 2012 03:00:05 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.136]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 02:00:05 +0200 From: To: Thread-Topic: Request to progress Netext WG I-D: draft-ietf-netext-access-network-option Thread-Index: AQHNHoiJiNuinp0r+EiBHur7RVk3Ow== Date: Fri, 20 Apr 2012 00:00:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [71.123.243.37] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C3DDDE872195E4B83C5DF49820D5C46@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2012 00:00:05.0745 (UTC) FILETIME=[8AD89E10:01CD1E88] X-Nokia-AV: Clean Cc: netext@ietf.org, draft-ietf-netext-access-network-option@tools.ietf.org Subject: [netext] Request to progress Netext WG I-D: draft-ietf-netext-access-network-option 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 00:00:15 -0000 Hello, The Netext WG I-D: Access Network Identifier (ANI) Option for Proxy Mobile IPv6 has completed working group last call and is ready for IESG review and publication. Please find the proto writeup for this I-D below. -Basavaraj (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor using proxy mobile IPv6 signaling messages. Working Group Summary The I-D has followed normal IETF WG process and has consensus regarding the proposed extension to Proxy Mobile IPv6. There have been no controversies or opposition to this proposal. Document Quality No known or announced implementations of the protocol exist. However there may be unannounced implementations in progress. Multiple vendors have indicated interest in implementing these extensions in their products. The I-D has undergone multiple reviews and they have been acknowledged in the document itself. =20 Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document shepherd: Basavaraj Patil Responsible AD: Brian Haberman (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed multiple versions of the I-D and have suggested changes to the text which have been incorporated. Questions about security (specifically provady) also have been addressed satisfactorily. Hence I believe the I-D is ready to be forwarded to the IESG.=20 (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. I am satisfied with the number as well as depth and breadth of the reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I do not believe there is a need for a broader review or review by specific experts from the area of security or internationalization etc.=20 (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns with this document and additionally do not believe that WG members have any concerns either. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Each of the author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure that references this I-D has been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is sufficient WG consensus behind this document. As has been the norm a few core contributors in the WG are supportive of the I-D and approve of it while the majority are silent. However I do believe that the WG as a whole understands this I-D and the proposed extensions. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threats of an appeal have been raised or for that matter extreme discontent with this I-D. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The idnits tool does not raise any flags or problems with this I-D. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This I-D does not specify a MIB, media type or URI type. (13) Have all references within this document been identified as either normative or informative? Yes.=20 (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No.=20 (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Publication of this document does not affect any existing RFCs. This I-D specifies an extension to Proxy MIP6 signaling and does not change the status of any other published RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). I have reviewed the IANA section and believe that sufficient and appropriate information w.r.t the proposed extensions, and the actions needed by IANA have been specified. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registry is proposed by this I-D. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This I-D does not include any XML code, BNF rules or MIB definitions which would require an automated check and review. From fu@cs.uni-goettingen.de Fri Apr 20 12:06:37 2012 Return-Path: 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 BFD7B21F85AC for ; Fri, 20 Apr 2012 12:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 LR7kgfsp08A0 for ; Fri, 20 Apr 2012 12:06:37 -0700 (PDT) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4675521F8565 for ; Fri, 20 Apr 2012 12:06:37 -0700 (PDT) Received: from p5484baab.dip.t-dialin.net ([84.132.186.171] helo=[192.168.0.103]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SLJAC-0007UH-0m; Fri, 20 Apr 2012 21:06:36 +0200 Message-ID: <4F91B48D.2060900@cs.uni-goettingen.de> Date: Fri, 20 Apr 2012 21:10:05 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie Subject: [netext] Call for papers: MobiArch 2012@ACM MOBICOM 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 19:06:37 -0000 (Apologies if you receive multiple copies of this CFP.) Call For Papers - MobiArch 2012 7th ACM Workshop on Mobility in the Evolving Internet Architecture In conjunction with ACM MOBICOM 2012, August 22-26, Istanbul, Turkey http://www.sigmobile.org/mobicom/2012/workshops.html http://www.research.att.com/~rjana/mobiarch.html Aim and Scope ------------- The objective of this workshop is to provide a forum for researchers and technologists to present the state-of-the-art contributions and discuss future directions in hot topics such as "economics and sustainability" and "mobile cloud computing" related to the architectures, services and applications in a mobile Internet era. The workshop will be organized in a manner designed to foster interaction and exchange of ideas among the participants. Besides paper presentations, time will be allocated to open discussion forums, informal discussions and panels. In addition to regular papers, vision or work-in-progress papers are also invited to stimulate debates on open problems and challenges. Proposals for panels are also solicited. Panel topics on emerging or even provocative topics that will generate lively discussions are especially welcome. Topics of interest for technical papers include, but are not limited to the following: Mobile pricing, incentives, network economics --------------------------------------------- - Technological and socio-economic aspects of mobile architectures, protocol design - Network pricing and congestion control - Wireless network neutrality - Cooperative schemes leveraging incentives - Economics of dynamic spectrum sharing - Incentive-aware wireless resource scheduling - Economics of deployment (infrastructure, devices and services) - Challenges and innovative pricing opportunities of mobile applications, social networking, advertisements - Performance and Fairness issues for an incentivized mobile network - Incentive mechanisms for mobile network security and privacy - Economic considerations in offering mobile computing services Mobile cloud technology and services ------------------------------------ - Mobile platforms, systems, applications, and services integrating with the clouds - Performance evaluation, measurement, and modeling of cloud based mobile services and applications - Resource discovery, allocation, scheduling, and management for cloud based mobile services - Partitioning technologies distributing computing workloads between clouds and mobile devices - Mobile web services integrating cloud computing infrastructure - Security and privacy issues for integrating clouds with mobile services - Mobile virtualization techniques and platforms - Economic analysis, revenue models, billing techniques for cloud based mobile services - Network and storage architectures for mobile clouds - Processing, mining, and storage of mobile context data using clouds Submissions will be solicited and all papers are subject to single blind reviews. Full technical papers: up to 6 pages in ACM format. Short position or demo papers: up to 2 pages in ACM format Workshop Deadlines ------------------ Abstracts due: May 20th, 2012 Submissions due: May 27th, 2012 Notification to authors: June 18, 2012 Camera-ready copy due: July 2, 2012 Paper Submission site: http://www.easychair.org/conferences/?conf=mobiarch2012 Workshop Chairs --------------- Rittwik Jana, AT&T Labs Research, USA Xiaoming Fu, University of Goettingen, Germany K K Ramakrishnan, AT&T Labs Research, USA Steering Committee: ------------------- Jon Crowcroft, University of Cambridge, UK Lars Eggert, Nokia Research Center, Finland Xiaoming Fu, University of Goettingen, Germany Marco Gruteser, Rutgers University, USA Katherine Guo, Bell Laboratories, USA Jörg Ott, Helsinki University of Technology, Finland Henning Schulzrinne, Columbia University, USA From Basavaraj.Patil@nokia.com Fri Apr 20 12:20:48 2012 Return-Path: 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 5965221F84E6 for ; Fri, 20 Apr 2012 12:20:48 -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=[AWL=0.000, 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 wM3MVZySwaD1 for ; Fri, 20 Apr 2012 12:20:47 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9228021F84DD for ; Fri, 20 Apr 2012 12:20:47 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3KJKfI4010358; Fri, 20 Apr 2012 22:20:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Apr 2012 22:20:41 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.3]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 21:20:40 +0200 From: To: Thread-Topic: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: AQHNEQ1ZU4UsKDirLE6Xqr8rotLyqJajvfoA Date: Fri, 20 Apr 2012 19:20:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <73B8FF7419630040B22D97AB858EA0D5@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2012 19:20:41.0325 (UTC) FILETIME=[ACE2E1D0:01CD1F2A] X-Nokia-AV: Clean Cc: draft-valmikam-eap-attributes-wifi-epc-integration@tools.ietf.org Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 19:20:48 -0000 Hello, I have not heard any negative views on adopting this I-D. I do believe that this I-D provides a good solution to the problem of indicating APN choice (in 3GPP networks) or handover indication (general applicability) to the MAG via EAP signaling. Hence it makes sense to adopt this I-D as a WG document and progress it as a Proposed Standard. I believe APN selection and Handover indication attributes within EAP messages are useful. I am not yet convinced about the multiple APN connectivity attribute. Hence I would recommend publishing this I-D as a WG doc with the scope limited to these two attributes. I-D Authors, please go ahead and publish the I-D as a Netext WG doc. -Raj =20 On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" wrote: > >Hello, > >At IETF83 the WG discussed the I-D : >draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >for WiFi - EPC Integration) > >This I-D proposes the use of EAP attributes as a means of signaling to >the MAG by an MN the parameters such as: >1. Choice of APN >2. Handover indication >3. Multiple APN connectivity > >These attributes are relevant in the context of an MN connecting via a >WiFi network to the 3GPP evolved packet core (EPC). > >The discussion in the WG favored using EAP attributes for parameters >(1) and (2) above. The multiple APN connectivity problem is harder to >solve.=20 > >Question to the WG members: >Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration >as a Netext WG document with the intent of standardizing the following >two attributes only : (1) Choice of APN and (2) Handover indication, to be >carried in EAP signaling at the time of network access authentication? > >Please respond to the ML (or to me privately) if you favor the adoption >of this I-D or are opposed to it. > >Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: > >Yes [ ] > >No [ ] > >-Basavaraj > >---------------------------------------------------- > >Abstract > > With WiFi beginning to establishing itself as a trusted access > network for service providers, it has become important to provide > functions commonly available in 3G and 4G networks in WiFi access > networks. Such functions include Access Point Name (APN) Selection, > multiple Packet Data Network (PDN) connections and seamless mobility > between WiFi and 3G/4G networks. > > EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access > authentication protocol for trusted access networks. This IETF > specification is required for mobile devices to access the 3GPP > Evolved Packet Core (EPC) networks. This document defines a few new > EAP attributes and procedures to provide the above-mentioned > functions in trusted WiFi access networks. > > From Basavaraj.Patil@nokia.com Fri Apr 20 12:34:26 2012 Return-Path: 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 D179921F85E1 for ; Fri, 20 Apr 2012 12:34:26 -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=[AWL=0.000, 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 Bjjyjxk2SZ1K for ; Fri, 20 Apr 2012 12:34:26 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1853B21F85C7 for ; Fri, 20 Apr 2012 12:34:26 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3KJYNEI021234; Fri, 20 Apr 2012 22:34:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Apr 2012 22:34:23 +0300 Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.3]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 21:34:11 +0200 From: To: Thread-Topic: Adopt I-D draft-korhonen-netext-rfc5149bis as Netext WG document? Thread-Index: AQHNEQvF2blscZIxjEWSCSFPRArsx5ajwcUA Date: Fri, 20 Apr 2012 19:34:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <689D84AA564DFB499BFFF81893482463@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2012 19:34:23.0952 (UTC) FILETIME=[9735CD00:01CD1F2C] X-Nokia-AV: Clean Cc: draft-korhonen-netext-rfc5149bis@tools.ietf.org, netext-chairs@tools.ietf.org Subject: Re: [netext] Adopt I-D draft-korhonen-netext-rfc5149bis as Netext WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 19:34:26 -0000 Hello, I believe that this I-D is beneficial to Proxy MIP6 deployments. I have not seen any negative opinions on adopting this as a WG document. Hence based on the consensus at the IETF83 WG meeting and the mailing list responses (or lack of), I recommend accepting this as a Netext WG I-D. Authors, please submit the I-D as WG doc. -Chairs On 4/2/12 3:04 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" wrote: > >Hello, > >At the Netext WG meeting at IETF83, the I-D Service Selection for >Mobile IPv6 was >discussed. We took a sense of the room to adopt the I-D as a working >group document and there was a strong consensus to do so. >Hence we are now asking the working group members over the mailing >list regarding the adoption of this I-D as a Netext working group >document. >Please respond to the ML or the chairs if you are in favor of or >against adopting this I-D as a WG document by April 16th, 2012. > >Question to WG members: >Should we adopt draft-korhonen-netext-rfc5149bis-02.txt as a Netext WG >document? > >Yes [ ] > >No [ ] > >-Chairs > >-------------------------------------------------------- > >Abstract > > In some Mobile IPv6 deployments, identifying the mobile node or the > mobility service subscriber is not enough to distinguish between > multiple services possibly provisioned to the said mobile node and > its mobility service subscription. A capability to specify different > services in addition to the mobile node identity can be leveraged to > provide flexibility for mobility service providers on provisioning > multiple services to one mobility service subscription. This > document describes a Service Selection Mobility Option for both > conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to > assist home agents and local mobility agents to make a specific > service selection for the mobility service subscription during the > binding registration procedure. This specification updates RFC5213 > and obsoletes RFC5149. > > From internet-drafts@ietf.org Mon Apr 23 10:23:51 2012 Return-Path: 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 EA94821F8766; Mon, 23 Apr 2012 10:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, 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 7rqeJ9H13zB3; Mon, 23 Apr 2012 10:23:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5766021F871C; Mon, 23 Apr 2012 10:23:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423172350.17072.52903.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 10:23:50 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-rfc5149bis-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:23:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Service Selection for Mobile IPv6 Author(s) : Jouni Korhonen Ulf Nilsson Vijay Devarapalli Filename : draft-ietf-netext-rfc5149bis-00.txt Pages : 12 Date : 2012-04-23 In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents and local mobility agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This specification updates RFC5213 and obsoletes RFC5149. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-rfc5149bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-rfc5149bis-00.txt From internet-drafts@ietf.org Mon Apr 23 11:23:44 2012 Return-Path: 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 332C021F869E; Mon, 23 Apr 2012 11:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, 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 40HBorTuwbBl; Mon, 23 Apr 2012 11:23:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2F21F8669; Mon, 23 Apr 2012 11:23:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423182343.462.96464.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 11:23:43 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:23:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : EAP Attributes for WiFi - EPC Integration Author(s) : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-00.txt Pages : 12 Date : 2012-04-23 With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attribut= es-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attribute= s-00.txt From brian@innovationslab.net Tue Apr 24 14:14:27 2012 Return-Path: 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 D5A9711E80B3 for ; Tue, 24 Apr 2012 14:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.345 X-Spam-Level: X-Spam-Status: No, score=-101.345 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 lDltvO37sGeq for ; Tue, 24 Apr 2012 14:14:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2E84A11E8083 for ; Tue, 24 Apr 2012 14:14:27 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2085C8810A; Tue, 24 Apr 2012 14:14:27 -0700 (PDT) Received: from clemson.wireless.jhu.edu (unknown [128.220.159.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A629C130017; Tue, 24 Apr 2012 14:14:26 -0700 (PDT) Message-ID: <4F9717B7.9030203@innovationslab.net> Date: Tue, 24 Apr 2012 17:14:31 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: draft-ietf-netext-access-network-option@tools.ietf.org, netext-chairs@tools.ietf.org, netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] AD Review: draft-ietf-netext-access-network-option 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 21:14:28 -0000 All, I have completed my AD review of this draft. For the most part, it is a well-written document. I have some comments, suggestions, and questions that should be relatively easy to deal with. 1. In the Introduction, the first paragraph talks about requiring the LMA to provide differentiated service and policing. Should this be an Informative reference to the DiffServ architecture (RFC 2475)? 2. It would be good to expand the PCC and ANDSF acronyms in the Intro for the uneducated reader. 3. The term "Web Page" does not need to be capitalized. 4. Introduction (2nd paragraph): - s/allows for carrying the/allows for the carrying of/ - the LMA acronym was already expanded - s/is a need for an additional/is a need for additional/ - s/an local mobility anchor/a local mobility anchor/ - insert "optionally" prior to "...carrying such information..." 5. Introduction (3rd paragraph): - add "the" before first instance of "Access Network Identifier" - s/used by mobile access gateway/used by the mobile access gateway/ - s/for carrying the access network/to signal the access network/ 6. Section 3: - The text for the ANI option says "...there can only be a single instance...". I would like to see this strengthened with the use of 2119 keywords. Would "...there MUST NOT be more than a single instance.." convey the point? - Similarly, would "The Access Network Identifier mobility option MUST contain one or more..." work? - The alignment requirement is useful, but I would also like a reference to how I interpret "4n". 7. Section 3.1.1 - s/that can be carried in Access/carried in the Access/ - s/There can only be a single instance/There MUST be no more than a single instance/ - The ANI Type MUST be set to a value of (1) - In the Network Name, MUST the SSID be used if it is 802.11? - s/digists/digits/ - Where do the MNC and MCC codes come from? - You will need a reference for UTF-8. - In AP-Name Length definition, it MUST be set to zero if the name is not carried? 8. Section 3.1.2 - s/that can be carried in Access/carried in the Access/ - "This sub-option carries the Geo-location..." - s/There can only be a single instance/There MUST be no more than a single instance/ - ANI Type: It MUST be set to a value of (2), ... - In ANI Length, I think it is better to say "MUST be set to a value of 8". - I would use MUSTs to define the acceptable ranges of the fields and specify what a receiver does when those ranges are violated. I would also capitalize the "must" in statements on rounding values. 9. Section 3.1.3: - The Operator-Identifier sub-option carries the operator... - s/There can only be a single instance/There MUST be no more than a single instance/ - The ANI Type MUST be set to a value of (3) - Should the reference to "Vendor ID" in Operator ID value 1 really be "Operator ID"? - What string encoding is supported for the Operator Identifier? 10. Section 4.1 - s/the following parameters must be/the following parameters MUST be/ - Are there recommended datatypes for the new parameters? - The 2nd bullet says the ANI option SHOULD be constructed as specified in Section 3. Why is this a SHOULD and not a MUST? - s/It should include the relevant/It SHOULD include the relevant/ and in what conditions would it not include the relevant sub-options? - s/through some of out of means/through some out-of-band means/ - The references to Section 6 when discussing the configuration variables need to be put in parenthesis. I would also like to see a discussion of when it is OK to violate the SHOULDs. - I am not sure I understand the following: "...the Proxy Binding Acknowledgement received from the local mobility anchor is also expected to contain...". SHOULD it contain the option? MUST it contain the option? 11. Section 4.2 - Same comment on whether there are recommended datatypes for the new parameters. And those parameters "MUST" be defined. - 3rd bullet: What does it mean to "agree with" the sub-option? - 3rd bullet: Is the last sentence necessary? - The 4th bullet seems clunky and is hard to parse. Can it be re-worded to state that if there is a matching session the old information MUST be removed. - I would suggest adding an "outside the scope of this document" clause to the 5th bullet. 12. Section 5 - I would suggest adding an example table structure for IANA actions 2 & 3. - Is there a potential recommendation for the Expert Reviewer that can be added to this section? 13. Section 6 - I would suggest re-wording the introductory sentence of each variable to something like: "This flag indicates the operational state of the ..." - Can you document rationale for why the SHOULDs are not MUSTs? Regards, Brian From internet-drafts@ietf.org Wed Apr 25 00:04:54 2012 Return-Path: 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 C942D21F8753; Wed, 25 Apr 2012 00:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 29+2pwjAZJt0; Wed, 25 Apr 2012 00:04:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FB421F873E; Wed, 25 Apr 2012 00:04:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120425070454.30894.91216.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 00:04:54 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 07:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-09.txt Pages : 18 Date : 2012-04-25 The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ From sgundave@cisco.com Wed Apr 25 00:05:51 2012 Return-Path: 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 5235321F8620 for ; Wed, 25 Apr 2012 00:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YflVVFOy22O9 for ; Wed, 25 Apr 2012 00:05:50 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EF48421F84C9 for ; Wed, 25 Apr 2012 00:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=7053; q=dns/txt; s=iport; t=1335337550; x=1336547150; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=JPxtSdRv3/7HqKQxxxaGwNOKLqXfWDr6M/R7jOfH6Fg=; b=XhE+mCeJvpnqvTlH+cI4qQ7qN5imOZMHfKBcnnod57v3oghqBsy/7t/N cHJEFwlNdlyDmc76DNgNujCrleQj8n5EHD9qUOt3ng9Kk26NTS2QP2asl l9PqXnQ3Y2PA/R2vQ+/WXCw4yFxtsHSl4JxrMJKABZOCnSqOe2pkC9oH0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALihl0+rRDoG/2dsb2JhbAA7CbFtgQeCCQEBAQMBAQEBDwEnAgEqBAMQDQEIElsiDgEBBAESIodoBAELml+gJASJa4EKhgIEiGONF45VgWmDCQ X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="42065243" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 25 Apr 2012 07:05:49 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3P75nKY026384; Wed, 25 Apr 2012 07:05:49 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 00:05:49 -0700 Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 07:05:48 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 25 Apr 2012 00:05:44 -0700 From: Sri Gundavelli To: Brian Haberman , , , Message-ID: Thread-Topic: [netext] AD Review: draft-ietf-netext-access-network-option Thread-Index: Ac0isdTlPvwtvHi/3EiEb4+9xuzq4w== In-Reply-To: <4F9717B7.9030203@innovationslab.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Apr 2012 07:05:49.0289 (UTC) FILETIME=[D80CDD90:01CD22B1] Subject: Re: [netext] AD Review: draft-ietf-netext-access-network-option 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 07:05:51 -0000 Hi Brian, Thanks a lot for your detailed review. Please see inline. I've posted the updated spec. On 4/24/12 2:14 PM, "Brian Haberman" wrote: > All, > I have completed my AD review of this draft. For the most part, > it is a well-written document. I have some comments, suggestions, and > questions that should be relatively easy to deal with. > > 1. In the Introduction, the first paragraph talks about requiring the > LMA to provide differentiated service and policing. Should this be an > Informative reference to the DiffServ architecture (RFC 2475)? > DiffServ based service treatment is probably just one example. > 2. It would be good to expand the PCC and ANDSF acronyms in the Intro > for the uneducated reader. > OK > 3. The term "Web Page" does not need to be capitalized. > OK > 4. Introduction (2nd paragraph): > - s/allows for carrying the/allows for the carrying of/ Ok > - the LMA acronym was already expanded Ok > - s/is a need for an additional/is a need for additional/ Ok > - s/an local mobility anchor/a local mobility anchor/ Ok > - insert "optionally" prior to "...carrying such information..." > OK > 5. Introduction (3rd paragraph): > - add "the" before first instance of "Access Network Identifier" Ok > - s/used by mobile access gateway/used by the mobile access gateway/ Ok > - s/for carrying the access network/to signal the access network/ > OK > 6. Section 3: > - The text for the ANI option says "...there can only be a single > instance...". I would like to see this strengthened with the use of > 2119 keywords. Would "...there MUST NOT be more than a single > instance.." convey the point? Agree > - Similarly, would "The Access Network Identifier mobility option MUST > contain one or more..." work? Agree > - The alignment requirement is useful, but I would also like a reference > to how I interpret "4n". > Wondering, which spec provides a good reference for this. 2460 Appendix ? > 7. Section 3.1.1 > - s/that can be carried in Access/carried in the Access/ Ok > - s/There can only be a single instance/There MUST be no more than a > single instance/ Ok > - The ANI Type MUST be set to a value of (1) Ok > - In the Network Name, MUST the SSID be used if it is 802.11? Yes > - s/digists/digits/ Ok > - Where do the MNC and MCC codes come from? 3GPP Specification 3GPP TS 23.003 > - You will need a reference for UTF-8. Ok. RFC 3629 > - In AP-Name Length definition, it MUST be set to zero if the name is > not carried? Reworded > > 8. Section 3.1.2 > - s/that can be carried in Access/carried in the Access/ ok > - "This sub-option carries the Geo-location..." Ok > - s/There can only be a single instance/There MUST be no more than a > single instance/ Ok > - ANI Type: It MUST be set to a value of (2), ... ok > - In ANI Length, I think it is better to say "MUST be set to a value of 8". Ok > - I would use MUSTs to define the acceptable ranges of the fields and > specify what a receiver does when those ranges are violated. I would > also capitalize the "must" in statements on rounding values. > Ok > 9. Section 3.1.3: > - The Operator-Identifier sub-option carries the operator... Ok > - s/There can only be a single instance/There MUST be no more than a > single instance/ ok > - The ANI Type MUST be set to a value of (3) Ok > - Should the reference to "Vendor ID" in Operator ID value 1 really be > "Operator ID"? No. Vendor Id is the term used for referring to the enterprise number. > - What string encoding is supported for the Operator Identifier? UTF-8. > > 10. Section 4.1 > - s/the following parameters must be/the following parameters MUST be/ Ok > - Are there recommended datatypes for the new parameters? We have not defined data types for conceptual data structure fields in most PMIP specs, so not sure, if we should do this now. We might be imposing a specific implementation, unless we are sure the suggested data types are the correct types > - The 2nd bullet says the ANI option SHOULD be constructed as specified > in Section 3. Why is this a SHOULD and not a MUST? MUST might be too strong. The feature may be enabled, but what if the MAG is unable to get all the needed parameters. > - s/It should include the relevant/It SHOULD include the relevant/ and Ok > in what conditions would it not include the relevant sub-options? Removed "relevant" > - s/through some of out of means/through some out-of-band means/ Ok > - The references to Section 6 when discussing the configuration > variables need to be put in parenthesis. I would also like to see a > discussion of when it is OK to violate the SHOULDs. Ok. "However, if the mobile access gateway is unable to obtain the operator identity, then it MUST NOT include this sub-option." > - I am not sure I understand the following: "...the Proxy Binding > Acknowledgement received from the local mobility anchor is also expected > to contain...". SHOULD it contain the option? MUST it contain the option? > SHOULD is probably ok > 11. Section 4.2 > - Same comment on whether there are recommended datatypes for the new > parameters. And those parameters "MUST" be defined. We have not defined data types for conceptual data structure fields in most PMIP specs, so not sure, if we should do this now. We might be imposing a specific implementation, unless we are sure the suggested data types are the correct types > - 3rd bullet: What does it mean to "agree with" the sub-option? If the LMA is enabled to support that sub-option > - 3rd bullet: Is the last sentence necessary? Removed > - The 4th bullet seems clunky and is hard to parse. Can it be re-worded > to state that if there is a matching session the old information MUST be > removed. Ok > - I would suggest adding an "outside the scope of this document" clause > to the 5th bullet. > I'm not sure I understood this comment > 12. Section 5 > - I would suggest adding an example table structure for IANA actions 2 & 3. Ok > - Is there a potential recommendation for the Expert Reviewer that can > be added to this section? > OK > 13. Section 6 > - I would suggest re-wording the introductory sentence of each variable > to something like: "This flag indicates the operational state of the ..." Ok > - Can you document rationale for why the SHOULDs are not MUSTs? MUST is too strong, IMO. The config variables may be turned on, but there are many other reasons where the MAG may be unable to construct the option. I've also added a reference to DHCP Geo Location spec, RFC 6225. > > Regards, > Brian > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From brian@innovationslab.net Wed Apr 25 05:54:04 2012 Return-Path: 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 77C3521F86DE for ; Wed, 25 Apr 2012 05:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 ij45xgWWaZpu for ; Wed, 25 Apr 2012 05:54:00 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7347821F86CE for ; Wed, 25 Apr 2012 05:54:00 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5B2B4880EE; Wed, 25 Apr 2012 05:54:00 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CEA36130017; Wed, 25 Apr 2012 05:53:59 -0700 (PDT) Message-ID: <4F97F3E5.6050704@innovationslab.net> Date: Wed, 25 Apr 2012 08:53:57 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, draft-ietf-netext-access-network-option@tools.ietf.org, netext-chairs@tools.ietf.org Subject: Re: [netext] AD Review: draft-ietf-netext-access-network-option 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 12:54:04 -0000 Sri, Thanks for the quick turnaround. I have trimmed the changes we agree on and the remaining follow-ups are in-line... On 4/25/12 3:05 AM, Sri Gundavelli wrote: >> - The alignment requirement is useful, but I would also like a reference >> to how I interpret "4n". >> > > Wondering, which spec provides a good reference for this. 2460 Appendix ? A reference to 2460 is sufficient. >> - Should the reference to "Vendor ID" in Operator ID value 1 really be >> "Operator ID"? > > No. Vendor Id is the term used for referring to the enterprise number. Ok. I parsed that sentence incorrectly. >> - Are there recommended datatypes for the new parameters? > > We have not defined data types for conceptual data structure fields in most > PMIP specs, so not sure, if we should do this now. We might be imposing a > specific implementation, unless we are sure the suggested data types are the > correct types > No need to if there is not precedence to do it. > >> - The 2nd bullet says the ANI option SHOULD be constructed as specified >> in Section 3. Why is this a SHOULD and not a MUST? > > MUST might be too strong. The feature may be enabled, but what if the MAG is > unable to get all the needed parameters. The inability to get the needed parameters falls under the first SHOULD about including the option, in my opinion. So, if the MAG cannot get those parameters, it doesn't send the option. When the MAG decides to include the option I would think it MUST construct the option based on Section 3. Which sub-options to include are driven by what information the MAG has available. If you don't construct the options in the formats defined in Section 3, how do you ensure correct handling? >> - Same comment on whether there are recommended datatypes for the new >> parameters. And those parameters "MUST" be defined. > > We have not defined data types for conceptual data structure fields in most > PMIP specs, so not sure, if we should do this now. We might be imposing a > specific implementation, unless we are sure the suggested data types are the > correct types Ok. >> - I would suggest adding an "outside the scope of this document" clause >> to the 5th bullet. >> > > I'm not sure I understood this comment Sorry for the terseness. I am thinking that the decision to use the ANI options are driven by policies/issues that are outside the scope of this specification. In other words, there is nothing in this document that controls how/when the operator applies the information contained in these options. > > >> 12. Section 5 >> - I would suggest adding an example table structure for IANA actions 2& 3. > Ok > >> - Is there a potential recommendation for the Expert Reviewer that can >> be added to this section? >> > > OK > > >> 13. Section 6 >> - I would suggest re-wording the introductory sentence of each variable >> to something like: "This flag indicates the operational state of the ..." > Ok > >> - Can you document rationale for why the SHOULDs are not MUSTs? > > MUST is too strong, IMO. The config variables may be turned on, but there > are many other reasons where the MAG may be unable to construct the option. Then I would suggest adding a sentence that explains that situation. > > I've also added a reference to DHCP Geo Location spec, RFC 6225. > Good. Regards, Brian From sgundave@cisco.com Wed Apr 25 06:48:49 2012 Return-Path: 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 EE76221F86DE for ; Wed, 25 Apr 2012 06:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ieGraNQkUnI2 for ; Wed, 25 Apr 2012 06:48:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DA44B21F86DA for ; Wed, 25 Apr 2012 06:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5869; q=dns/txt; s=iport; t=1335361723; x=1336571323; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=5GxDS7qXxPcr9ZhkEXWrE/vzpZ9sQcgAoNWMlOCKYnY=; b=luyWjHjZjrA/V4VRZGp3WN7QtNyksO6Epj8mOKA/+FO9aE3EpQRHWvOv a/B3f3A9fZisLKfM3wLHS2mMO3NvmJkMWHIHavGHOQJbh54ON26EDHvUu XDqmHuYdUYw5xM1O7XKIQd7ae2IQLeXcyablxwMsk6qfp/s4V8gDmeeeg Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALn/l0+rRDoH/2dsb2JhbABFsUuBB4IJAQEBAwESAScCAS4OBQ0BCBiBBQEBBA4FIodoBJsVoC2QdwSIY40YjlWBaYMJgTQH X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="42103402" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 25 Apr 2012 13:48:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3PDmgIM002149; Wed, 25 Apr 2012 13:48:42 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 06:48:42 -0700 Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 13:48:42 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 25 Apr 2012 06:48:37 -0700 From: Sri Gundavelli To: Brian Haberman Message-ID: Thread-Topic: [netext] AD Review: draft-ietf-netext-access-network-option Thread-Index: Ac0i6h0gRKaSopyT1EOOo3QUIDQOdQ== In-Reply-To: <4F97F3E5.6050704@innovationslab.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Apr 2012 13:48:42.0466 (UTC) FILETIME=[2062F420:01CD22EA] Cc: netext@ietf.org, draft-ietf-netext-access-network-option@tools.ietf.org, netext-chairs@tools.ietf.org Subject: Re: [netext] AD Review: draft-ietf-netext-access-network-option 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:48:49 -0000 Hi Brian, Thanks for the quick response. Please see inline. On 4/25/12 5:53 AM, "Brian Haberman" wrote: > Sri, > Thanks for the quick turnaround. I have trimmed the changes we > agree on and the remaining follow-ups are in-line... > > On 4/25/12 3:05 AM, Sri Gundavelli wrote: > >>> - The alignment requirement is useful, but I would also like a reference >>> to how I interpret "4n". >>> >> >> Wondering, which spec provides a good reference for this. 2460 Appendix ? > > A reference to 2460 is sufficient. > Ok >>> - Should the reference to "Vendor ID" in Operator ID value 1 really be >>> "Operator ID"? >> >> No. Vendor Id is the term used for referring to the enterprise number. > > Ok. I parsed that sentence incorrectly. > Ok >>> - Are there recommended datatypes for the new parameters? >> >> We have not defined data types for conceptual data structure fields in most >> PMIP specs, so not sure, if we should do this now. We might be imposing a >> specific implementation, unless we are sure the suggested data types are the >> correct types >> > > No need to if there is not precedence to do it. > Ok >> >>> - The 2nd bullet says the ANI option SHOULD be constructed as specified >>> in Section 3. Why is this a SHOULD and not a MUST? >> >> MUST might be too strong. The feature may be enabled, but what if the MAG is >> unable to get all the needed parameters. > > The inability to get the needed parameters falls under the first SHOULD > about including the option, in my opinion. So, if the MAG cannot get > those parameters, it doesn't send the option. When the MAG decides to > include the option I would think it MUST construct the option based on > Section 3. Which sub-options to include are driven by what information > the MAG has available. If you don't construct the options in the > formats defined in Section 3, how do you ensure correct handling? > I agree for the use of MUST for the "construct" clause; I did not read my text carefully. How about this: "If the mobile access gateway is configured to support Access Network Information option, it SHOULD include this option with the specific sub-options in all Proxy Binding Update messages (including in Proxy Binding Updates for lifetime extension and for deregistration) that it sends to the local mobility anchor. The Access Network Information option MUST be constructed as specified in Section 3. It SHOULD include the ANI sub-option(s) that the mobile access gateway is configured to carry them in the Proxy Mobile IPv6 messages." > >>> - I would suggest adding an "outside the scope of this document" clause >>> to the 5th bullet. >>> >> >> I'm not sure I understood this comment > > Sorry for the terseness. I am thinking that the decision to use the ANI > options are driven by policies/issues that are outside the scope of this > specification. In other words, there is nothing in this document that > controls how/when the operator applies the information contained in > these options. >> I got it now. How about this. Section 4.2 (Last bullet point): "The local mobility anchor MAY choose to use the access network information sub-options for applying any access operator specific handling or policing of the mobile node traffic. The specific details on how these sub-options are used is outside the scope of this document." >> >>> 12. Section 5 >>> - I would suggest adding an example table structure for IANA actions 2& 3. >> Ok >> I've added to the tables IANA actions 2 and 3. +=========================================================+ | 0 | Reserved | +=========================================================+ | 1 | Network-Identifier Sub-option | +=========================================================+ | 2 | Geo-Location Sub-option | +=========================================================+ | 3 | Operator-Identifier Sub-option | +=========================================================+ +=========================================================+ | 0 | Reserved | +===+=====================================================+ | 1 | Vendor ID as a four octet Private Enterprise Number | +===+=====================================================+ | 2 | Realm of the Operator | +===+=====================================================+ >>> - Is there a potential recommendation for the Expert Reviewer that can >>> be added to this section? >>> >> >> OK One of the Authors ? >> >> >>> 13. Section 6 >>> - I would suggest re-wording the introductory sentence of each variable >>> to something like: "This flag indicates the operational state of the ..." >> Ok >> This is what I've: This flag indicates the operational state of the Network-Identifier sub-option support. .. This flag indicates the operational state of the Geo-Location sub-option support. .. This flag indicates the operational state of the Operator-Identifier sub-option support. >>> - Can you document rationale for why the SHOULDs are not MUSTs? >> >> MUST is too strong, IMO. The config variables may be turned on, but there >> are many other reasons where the MAG may be unable to construct the option. > > Then I would suggest adding a sentence that explains that situation. > How about some thing like this for each of the variables ? "There can be situations where the MAG is unable to obtain the network name and be able to construct the option." Regards Sri From brian@innovationslab.net Wed Apr 25 07:43:42 2012 Return-Path: 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 3688021F866D for ; Wed, 25 Apr 2012 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 EmUs8o+rz4An for ; Wed, 25 Apr 2012 07:43:41 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7914D21F8669 for ; Wed, 25 Apr 2012 07:43:41 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 678558810D; Wed, 25 Apr 2012 07:43:41 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C67EF130017; Wed, 25 Apr 2012 07:43:40 -0700 (PDT) Message-ID: <4F980D9C.2020602@innovationslab.net> Date: Wed, 25 Apr 2012 10:43:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, draft-ietf-netext-access-network-option@tools.ietf.org, netext-chairs@tools.ietf.org Subject: Re: [netext] AD Review: draft-ietf-netext-access-network-option 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 14:43:42 -0000 On 4/25/12 9:48 AM, Sri Gundavelli wrote: >>>> - The 2nd bullet says the ANI option SHOULD be constructed as specified >>>> in Section 3. Why is this a SHOULD and not a MUST? >>> >>> MUST might be too strong. The feature may be enabled, but what if the MAG is >>> unable to get all the needed parameters. >> >> The inability to get the needed parameters falls under the first SHOULD >> about including the option, in my opinion. So, if the MAG cannot get >> those parameters, it doesn't send the option. When the MAG decides to >> include the option I would think it MUST construct the option based on >> Section 3. Which sub-options to include are driven by what information >> the MAG has available. If you don't construct the options in the >> formats defined in Section 3, how do you ensure correct handling? >> > > I agree for the use of MUST for the "construct" clause; I did not read my > text carefully. How about this: > > "If the mobile access gateway is configured to support Access Network > Information option, it SHOULD include this option with the specific > sub-options in all Proxy Binding Update messages (including in Proxy Binding > Updates for lifetime extension and for deregistration) that it sends to the > local mobility anchor. The Access Network Information option MUST be > constructed as specified in Section 3. It SHOULD include the ANI > sub-option(s) that the mobile access gateway is configured to carry them in > the Proxy Mobile IPv6 messages." > Drop the "them" from the last sentence and that works for me. > >> >>>> - I would suggest adding an "outside the scope of this document" clause >>>> to the 5th bullet. >>>> >>> >>> I'm not sure I understood this comment >> >> Sorry for the terseness. I am thinking that the decision to use the ANI >> options are driven by policies/issues that are outside the scope of this >> specification. In other words, there is nothing in this document that >> controls how/when the operator applies the information contained in >> these options. >>> > > I got it now. How about this. > > Section 4.2 (Last bullet point): > > "The local mobility anchor MAY choose to use the access network information > sub-options for applying any access operator specific handling or policing > of the mobile node traffic. The specific details on how these sub-options > are used is outside the scope of this document." > Sounds good. > >>> >>>> 12. Section 5 >>>> - I would suggest adding an example table structure for IANA actions 2& 3. >>> Ok >>> > > I've added to the tables IANA actions 2 and 3. > > > +=========================================================+ > | 0 | Reserved | > +=========================================================+ > | 1 | Network-Identifier Sub-option | > +=========================================================+ > | 2 | Geo-Location Sub-option | > +=========================================================+ > | 3 | Operator-Identifier Sub-option | > +=========================================================+ > > > +=========================================================+ > | 0 | Reserved | > +===+=====================================================+ > | 1 | Vendor ID as a four octet Private Enterprise Number | > +===+=====================================================+ > | 2 | Realm of the Operator | > +===+=====================================================+ > Good. > > >>>> - Is there a potential recommendation for the Expert Reviewer that can >>>> be added to this section? >>>> >>> >>> OK > > One of the Authors ? > > That is fine. There is no need to include that in the draft. I will pass that information along to IANA when they review the document. > >>> >>> >>>> 13. Section 6 >>>> - I would suggest re-wording the introductory sentence of each variable >>>> to something like: "This flag indicates the operational state of the ..." >>> Ok >>> > > This is what I've: > > This flag indicates the operational state of the Network-Identifier > sub-option support. > .. > This flag indicates the operational state of the Geo-Location sub-option > support. > .. > This flag indicates the operational state of the Operator-Identifier > sub-option support. > Ok. > > >>>> - Can you document rationale for why the SHOULDs are not MUSTs? >>> >>> MUST is too strong, IMO. The config variables may be turned on, but there >>> are many other reasons where the MAG may be unable to construct the option. >> >> Then I would suggest adding a sentence that explains that situation. >> > > How about some thing like this for each of the variables ? > > "There can be situations where the MAG is unable to obtain the network name > and be able to construct the option." > Works for me. Regards, Brian From internet-drafts@ietf.org Wed Apr 25 08:32:29 2012 Return-Path: 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 87D6221F87CB; Wed, 25 Apr 2012 08:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, 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 zU16TRoxDdEb; Wed, 25 Apr 2012 08:32:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0297121F8715; Wed, 25 Apr 2012 08:32:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120425153229.3581.49448.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 08:32:29 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-access-network-option-10.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:32:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Access Network Identifier (ANI) Option for Proxy Mobile = IPv6 Author(s) : Sri Gundavelli Jouni Korhonen Mark Grayson Kent Leung Rajesh Pazhyannur Filename : draft-ietf-netext-access-network-option-10.txt Pages : 18 Date : 2012-04-25 The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-access-network-option= -10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-access-network-option-= 10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ From sgundave@cisco.com Wed Apr 25 08:33:15 2012 Return-Path: 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 DC34021F87D0 for ; Wed, 25 Apr 2012 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wz4LKNWuJ6Eb for ; Wed, 25 Apr 2012 08:33:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 747B021F8772 for ; Wed, 25 Apr 2012 08:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5492; q=dns/txt; s=iport; t=1335367994; x=1336577594; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0xEV1ikXORTMzNh6g6/zXVOe8JkkA3W0hljDGywbp/o=; b=OQLLTJRIY6sqZx1boNzf41+jMLwwGklsGyy4Ik411PQomMKkHijdG6jf 2iur9JbWPgwIH9ZawAqZpbwVazsSRD5ghS28AGbAE2rTYkaftXilKnDnn PNDVTMUA3ZBtwm9k4cZUHPL6I8DClkeJvjhDfgM1x0cczAGiRX9aE2SW/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK8YmE+rRDoH/2dsb2JhbABFsUyBB4IJAQEBAwESAScCAS4OBQ0BCBiBBQEBBA4FIodoBAGbLaAokHcEiGONGI5VgWmDCYE0Bw X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="39541786" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 25 Apr 2012 15:33:14 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3PFXDds021672; Wed, 25 Apr 2012 15:33:14 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 08:33:13 -0700 Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 15:33:13 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 25 Apr 2012 08:33:08 -0700 From: Sri Gundavelli To: Brian Haberman Message-ID: Thread-Topic: [netext] AD Review: draft-ietf-netext-access-network-option Thread-Index: Ac0i+LbvSWGzj95UQUqozDEMcpt59A== In-Reply-To: <4F980D9C.2020602@innovationslab.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Apr 2012 15:33:13.0858 (UTC) FILETIME=[BA6D6E20:01CD22F8] Cc: netext@ietf.org, draft-ietf-netext-access-network-option@tools.ietf.org, netext-chairs@tools.ietf.org Subject: Re: [netext] AD Review: draft-ietf-netext-access-network-option 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:33:16 -0000 Thanks Brian. Revised version posted. Sri On 4/25/12 7:43 AM, "Brian Haberman" wrote: > On 4/25/12 9:48 AM, Sri Gundavelli wrote: > >>>>> - The 2nd bullet says the ANI option SHOULD be constructed as specified >>>>> in Section 3. Why is this a SHOULD and not a MUST? >>>> >>>> MUST might be too strong. The feature may be enabled, but what if the MAG >>>> is >>>> unable to get all the needed parameters. >>> >>> The inability to get the needed parameters falls under the first SHOULD >>> about including the option, in my opinion. So, if the MAG cannot get >>> those parameters, it doesn't send the option. When the MAG decides to >>> include the option I would think it MUST construct the option based on >>> Section 3. Which sub-options to include are driven by what information >>> the MAG has available. If you don't construct the options in the >>> formats defined in Section 3, how do you ensure correct handling? >>> >> >> I agree for the use of MUST for the "construct" clause; I did not read my >> text carefully. How about this: >> >> "If the mobile access gateway is configured to support Access Network >> Information option, it SHOULD include this option with the specific >> sub-options in all Proxy Binding Update messages (including in Proxy Binding >> Updates for lifetime extension and for deregistration) that it sends to the >> local mobility anchor. The Access Network Information option MUST be >> constructed as specified in Section 3. It SHOULD include the ANI >> sub-option(s) that the mobile access gateway is configured to carry them in >> the Proxy Mobile IPv6 messages." >> > > Drop the "them" from the last sentence and that works for me. > >> >>> >>>>> - I would suggest adding an "outside the scope of this document" clause >>>>> to the 5th bullet. >>>>> >>>> >>>> I'm not sure I understood this comment >>> >>> Sorry for the terseness. I am thinking that the decision to use the ANI >>> options are driven by policies/issues that are outside the scope of this >>> specification. In other words, there is nothing in this document that >>> controls how/when the operator applies the information contained in >>> these options. >>>> >> >> I got it now. How about this. >> >> Section 4.2 (Last bullet point): >> >> "The local mobility anchor MAY choose to use the access network information >> sub-options for applying any access operator specific handling or policing >> of the mobile node traffic. The specific details on how these sub-options >> are used is outside the scope of this document." >> > > Sounds good. > >> >>>> >>>>> 12. Section 5 >>>>> - I would suggest adding an example table structure for IANA actions 2& >>>>> 3. >>>> Ok >>>> >> >> I've added to the tables IANA actions 2 and 3. >> >> >> +=========================================================+ >> | 0 | Reserved | >> +=========================================================+ >> | 1 | Network-Identifier Sub-option | >> +=========================================================+ >> | 2 | Geo-Location Sub-option | >> +=========================================================+ >> | 3 | Operator-Identifier Sub-option | >> +=========================================================+ >> >> >> +=========================================================+ >> | 0 | Reserved | >> +===+=====================================================+ >> | 1 | Vendor ID as a four octet Private Enterprise Number | >> +===+=====================================================+ >> | 2 | Realm of the Operator | >> +===+=====================================================+ >> > > Good. > >> >> >>>>> - Is there a potential recommendation for the Expert Reviewer that can >>>>> be added to this section? >>>>> >>>> >>>> OK >> >> One of the Authors ? >> >> > > That is fine. There is no need to include that in the draft. I will > pass that information along to IANA when they review the document. > >> >>>> >>>> >>>>> 13. Section 6 >>>>> - I would suggest re-wording the introductory sentence of each variable >>>>> to something like: "This flag indicates the operational state of the ..." >>>> Ok >>>> >> >> This is what I've: >> >> This flag indicates the operational state of the Network-Identifier >> sub-option support. >> .. >> This flag indicates the operational state of the Geo-Location sub-option >> support. >> .. >> This flag indicates the operational state of the Operator-Identifier >> sub-option support. >> > > Ok. > >> >> >>>>> - Can you document rationale for why the SHOULDs are not MUSTs? >>>> >>>> MUST is too strong, IMO. The config variables may be turned on, but there >>>> are many other reasons where the MAG may be unable to construct the option. >>> >>> Then I would suggest adding a sentence that explains that situation. >>> >> >> How about some thing like this for each of the variables ? >> >> "There can be situations where the MAG is unable to obtain the network name >> and be able to construct the option." >> > > Works for me. > > Regards, > Brian > From sarikaya2012@gmail.com Wed Apr 25 08:40:07 2012 Return-Path: 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 0CF7B21F87D0 for ; Wed, 25 Apr 2012 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XD7+3IdkPCGD for ; Wed, 25 Apr 2012 08:40:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC82C21F87CB for ; Wed, 25 Apr 2012 08:40:05 -0700 (PDT) Received: by iazz13 with SMTP id z13so269992iaz.31 for ; Wed, 25 Apr 2012 08:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=oWOJ2W4rcTImyFkrK4BxS2ihcNLss2FX+yJz/i2RYDM=; b=G/1KVCgUFRHwguiiiOd/2fi3+xvQz3zc2n32h4rUnB9vUkP756DHH10jZizlnf4ndj ZgcwEorJId9zk8vUvoOlBJqAPW5D06BEBWiXs4WpWPxMhqTvOLwKhJYUwvNVb8kQIjkT Lte6HKoDBGPWS3X0djFGFCTSj7pZPe//glF7d0y9Z4uZa/cx6J77ouyV/qidNvUy+S1X NMpJ3mAn5XlCFB4NbUZJPi0vFwLAbRU1kZ32h0BccV/9FELHWgc5qPquZvPkPkLNsEpo t8scKOuGlSYG3mZlT9OX8zdWg308GiuHGqHY0wcSUvMKx1Nkv7l7XiNyhKqBbnavZkv/ /c+Q== MIME-Version: 1.0 Received: by 10.50.85.232 with SMTP id k8mr14882620igz.16.1335368405484; Wed, 25 Apr 2012 08:40:05 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Wed, 25 Apr 2012 08:40:05 -0700 (PDT) In-Reply-To: <20120423182343.462.96464.idtracker@ietfa.amsl.com> References: <20120423182343.462.96464.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 10:40:05 -0500 Message-ID: From: Behcet Sarikaya To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 25 Apr 2012 15:40:07 -0000 Hi Basavaraj, chairs, I read this document and have some questions on it: The draft is on defining 4 new EAP attributes and how to use them. PMIPv6 relevance is very tangential, the document mentions PMIPv6 as one possible deployment choice in Section 3.2 and that's all. If you look at the call flow in Fig.1 there is no PMIPv6 at all. The main purpose of this document seems to be to define four new EAP attributes to be sent by the Mobile Node in 802.1X based authentication exchanges over Wi-Fi links. All these bring a lot of questions to one's mind: 1. Given that the draft wants to define NEW EAP attributes to be sent by MN= , it is clearly extending MN. This seems to be so obvious. So the question is: can Netext work on such documents? The charter clearly states that proxy mobility is based on network proxying the MN so that we don't change MN? Is this acceptable to the chairs? Is this acceptable to WG? Is this acceptable to IESG? I have cc'ed to Brian. 2. As I said above, the draft's main concern is MN authentication on Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links and Wi-Fi link is a shared link. Does this raise any concerns to you? 3. This one is procedural. What about the charter? The current charter talks about Localized Routing, Bulk Refresh and LMA Redirection and logical interface. I could not see defining new EAP attributes in the charter? Kind regards, Behcet PS. I wanted to bring to the attention the concerns I personally have. No offense to anyone, please. On Mon, Apr 23, 2012 at 1:23 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Network-Based Mobility Extensions W= orking Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : EAP Attributes for WiFi - EPC = Integration > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Ravi Valmikam > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rajeev Koodli > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-wifi-epc-eap-a= ttributes-00.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-23 > > =A0 With WiFi beginning to establishing itself as a trusted access > =A0 network for service providers, it has become important to provide > =A0 functions commonly available in 3G and 4G networks in WiFi access > =A0 networks. =A0Such functions include Access Point Name (APN) Selection= , > =A0 multiple Packet Data Network (PDN) connections and seamless mobility > =A0 between WiFi and 3G/4G networks. > > =A0 EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access > =A0 authentication protocol for trusted access networks. =A0This IETF > =A0 specification is required for mobile devices to access the 3GPP > =A0 Evolved Packet Core (EPC) networks. =A0This document defines a few ne= w > =A0 EAP attributes and procedures to provide the above-mentioned > =A0 functions in trusted WiFi access networks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attrib= utes-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attribu= tes-00.txt > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From iesg-secretary@ietf.org Wed Apr 25 10:37:47 2012 Return-Path: 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 0408521F8833; Wed, 25 Apr 2012 10:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, 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 XqlutZx4Oi8q; Wed, 25 Apr 2012 10:37:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D50121F87F4; Wed, 25 Apr 2012 10:37:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120425173746.2695.33210.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 10:37:46 -0700 Cc: netext@ietf.org Subject: [netext] Last Call: (Access Network Identifier (ANI) Option for Proxy Mobile IPv6) to Proposed Standard X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 25 Apr 2012 17:37:47 -0000 The IESG has received a request from the Network-Based Mobility Extensions WG (netext) to consider the following document: - 'Access Network Identifier (ANI) Option for Proxy Mobile IPv6' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ballot/ No IPR declarations have been submitted directly on this I-D. From Basavaraj.Patil@nokia.com Wed Apr 25 13:01:54 2012 Return-Path: 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 D99E721F885D for ; Wed, 25 Apr 2012 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_33=1, 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 Scoq4dN2IE63 for ; Wed, 25 Apr 2012 13:01:54 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E455C21F881B for ; Wed, 25 Apr 2012 13:01:53 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3PK1l3Z030651; Wed, 25 Apr 2012 23:01:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 23:01:47 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.48]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Wed, 25 Apr 2012 22:01:45 +0200 From: To: , Thread-Topic: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt Thread-Index: AQHNIvmxXoE5SUVh4EqssCBV4/H4f5argS0A Date: Wed, 25 Apr 2012 20:01:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <51875E366B683C4C8DC2096F0E357591@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Apr 2012 20:01:47.0417 (UTC) FILETIME=[3EDB6890:01CD231E] X-Nokia-AV: Clean Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:01:55 -0000 Response inline: On 4/25/12 10:40 AM, "ext Behcet Sarikaya" wrote: >Hi Basavaraj, chairs, Please note that I am the sole chair responsible for this I-D (as mentioned in a previous email as well to the list). > >I read this document and have some questions on it: > >The draft is on defining 4 new EAP attributes and how to use them. > >PMIPv6 relevance is very tangential, It is very much relevant. The use case has been presented quite clearly. Given the lack of MN-MAG signaling at L3, the MN/UE cannot provide indications such as Choice of APN (relevant in the 3GP context) or HO indication to a MAG. By adding these attributes to EAP signaling an MN can accomplish this task. The MN needs to authenticate with the access network to which it attaches and this information can be signaled to the AN/MAG at the time of attachment. > > the document mentions PMIPv6 as one possible deployment choice in >Section 3.2 and that's all. The I-D can elaborate further on how it ties in with PMIP6 for further clarification if needed. > >If you look at the call flow in Fig.1 there is no PMIPv6 at all. Right. That is because the APN choice and HO indication happens prior to PMIP6 signaling (BU/BA). This information is used subsequently by MAG<->LMA signaling which can be shown in the figure if that helps. > >The main purpose of this document seems to be to define four new EAP >attributes to be sent by the Mobile Node in 802.1X based >authentication exchanges over Wi-Fi links. > >All these bring a lot of questions to one's mind: > >1. Given that the draft wants to define NEW EAP attributes to be sent by >MN, > > it is clearly extending MN. > >This seems to be so obvious. Yes. That is well understood. > >So the question is: can Netext work on such documents? The charter >clearly states that proxy mobility is based on network proxying the MN >so that we don't change MN? We are extending EAP signaling with the attributes. This does not mean that we are creating a new MN-MAG signaling protocol which is out of scope of this WG. You are misinterpreting what is intended by the statement "No changes to the MN w.r.t PMIP6". > >Is this acceptable to the chairs? Yes.=20 > >Is this acceptable to WG? Consensus call was issued previously with no negative feedback. > >Is this acceptable to IESG? I have cc'ed to Brian. Good.=20 > >2. As I said above, the draft's main concern is MN authentication on >Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links >and Wi-Fi link is a shared link. >Does this raise any concerns to you? No.=20 > >3. This one is procedural. What about the charter? The current charter >talks about Localized Routing, Bulk Refresh and LMA Redirection and >logical interface. I could not see defining new EAP attributes in the >charter? Charter also says: "The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed." This work item as well as Service Selection for Mobile IPv6 will be added to the charter milestones. -Raj > >Kind regards, > >Behcet > >PS. I wanted to bring to the attention the concerns I personally have. >No offense to anyone, please. > >On Mon, Apr 23, 2012 at 1:23 PM, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. This draft is a work item of the Network-Based Mobility >>Extensions Working Group of the IETF. >> >> Title : EAP Attributes for WiFi - EPC Integration >> Author(s) : Ravi Valmikam >> Rajeev Koodli >> Filename : >>draft-ietf-netext-wifi-epc-eap-attributes-00.txt >> Pages : 12 >> Date : 2012-04-23 >> >> With WiFi beginning to establishing itself as a trusted access >> network for service providers, it has become important to provide >> functions commonly available in 3G and 4G networks in WiFi access >> networks. Such functions include Access Point Name (APN) Selection, >> multiple Packet Data Network (PDN) connections and seamless mobility >> between WiFi and 3G/4G networks. >> >> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >> authentication protocol for trusted access networks. This IETF >> specification is required for mobile devices to access the 3GPP >> Evolved Packet Core (EPC) networks. This document defines a few new >> EAP attributes and procedures to provide the above-mentioned >> functions in trusted WiFi access networks. >> >> >> A URL for this Internet-Draft is: >>=20 >>http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attrib >>utes-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >>=20 >>ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attribu >>tes-00.txt >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Wed Apr 25 13:37:00 2012 Return-Path: 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 6595C21F8883 for ; Wed, 25 Apr 2012 13:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 l+ZO+j0zb3tv for ; Wed, 25 Apr 2012 13:36:59 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 73F1221F8777 for ; Wed, 25 Apr 2012 13:36:59 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3PKauSi005413; Wed, 25 Apr 2012 23:36:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 23:36:56 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.48]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Wed, 25 Apr 2012 22:36:43 +0200 From: To: Thread-Topic: Milestone update for NetExt WG Thread-Index: AQHNIyMgDFG/gVNRlk2qm5eFUf23fg== Date: Wed, 25 Apr 2012 20:36:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.38] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Apr 2012 20:36:56.0033 (UTC) FILETIME=[27B0AD10:01CD2323] X-Nokia-AV: Clean Cc: netext@ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Milestone update for NetExt WG 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:37:00 -0000 Hi Brian, The milestones for the Netext WG are outdated and hence we would like to propose revising the same. Please see the proposal below. Let me know if I should submit the same to the IESG secretary. -Chairs As of: Apr 25, 2012: Goals and Milestones Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Mar 2010 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Mar 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 May 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC May 2010 Initial WG draft on Localized Routing Solution Jul 2010 Initial WG document on Applicability Statement on Logical Interface over Multiple Physical Interfaces Jul 2010 WG decision on what Proxy Mobile IPv6 mechanisms are needed to support flow mobility and inter-access handovers on a logical interface over multiple physical interfaces Oct 2010 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 Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) =20 Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC ------------------------------------------------------------ A few of the delivereables that have been completed (or close to completion): 1. Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 has been published as RFC6463 2. Bulk Binding Update Support for Proxy Mobile IPv6 is in the RFC editors queue 3. RADIUS Support for Proxy Mobile IPv6 is in the RFC editors queue 4. Localized Routing for Proxy Mobile IPv6 has completed IETF LC and IESG DISCUSSES are being dealt with by the editor. Revised set of milestones for the WG below: Apr 2012 Initial WG document on Service Selection for MIP6 and PMIP6 Apr 2012 Initial WG document on EAP Attributes for WiFi - EPC Integration Apr 2012 Submit Access Network Identifier (ANI) Option for PMIP6 to IESG for publication as a proposed standard Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for publication as a proposed standard Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 to IESG for publication as a proposed standard Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for publication as a proposed standard Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the IESG for publication as a proposed standard Apr 2013 Submit Logical Interface Support for multi-mode IP Hosts for publication as an Informational document May 2013 Submit EAP Attributes for WiFi - EPC Integration to IESG for publication as a proposed standard From rkoodli@cisco.com Wed Apr 25 14:46:50 2012 Return-Path: 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 625C121F894B for ; Wed, 25 Apr 2012 14:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.901 X-Spam-Level: X-Spam-Status: No, score=-109.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 g7oiPAIS-kAY for ; Wed, 25 Apr 2012 14:46:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0898621F8949 for ; Wed, 25 Apr 2012 14:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=5638; q=dns/txt; s=iport; t=1335390403; x=1336600003; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=NZ+KUHSu1LkBNL2nPnjgqw20pCGPOzyvF5J9NWuiIh0=; b=TrGFueUET1J7+N8pKCKWDjpYZE84RJFu7acIBnrDxl5OxEEAubb5CUTV xF+ggqdx8L9VtI5VhAMR70FFZD7d8IQU3gfUpH9cVZiROJO/NPZCmxjOp ofY0VKpnGY+Pm3Z1yZ+MXhfbWOOg3h+V2Lj/kmmkcvf7kp893C4fqXf7s c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAKADhwmE+tJXHB/2dsb2JhbABFsDUDFoEAgQeCCQEBAQMBAQEBDwEpATEQDQEIGE8GMAEBBAESCRmFb4FwAwYFC5s2ljgNiVOJaxKBa4R4BIgvNI0Yiz2DGIFpgwmBPA X-IronPort-AV: E=Sophos;i="4.75,483,1330905600"; d="scan'208";a="77884663" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 25 Apr 2012 21:46:42 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3PLkgFM005419; Wed, 25 Apr 2012 21:46:42 GMT Received: from xmb-rcd-214.cisco.com ([72.163.62.221]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 16:46:42 -0500 Received: from 10.21.76.228 ([10.21.76.228]) by XMB-RCD-214.cisco.com ([72.163.62.221]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 21:46:41 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 25 Apr 2012 14:52:00 -0700 From: Rajeev Koodli To: , Message-ID: Thread-Topic: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt Thread-Index: Ac0jLaRDRtmNjw40iU2IH6Y10Ywtow== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Apr 2012 21:46:42.0078 (UTC) FILETIME=[E6C473E0:01CD232C] Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 21:46:50 -0000 Hi Behcet, Thanks for reading. Comments inline.. On 4/25/12 8:40 AM, "Behcet Sarikaya" wrote: > I read this document and have some questions on it: >=20 > The draft is on defining 4 new EAP attributes and how to use them. >=20 > PMIPv6 relevance is very tangential, >=20 Wrong. It's similar to the PMIP6 Radius ID, of which you are a co-author :-= ) You could argue that defining Radius attributes has nothing do with PMIP6, but that's not the case - PMIP6 signaling benefits/relies on such attributes. The MAG needs to know few elements to populate in the PBU, such as the APN and HI. The ID is defining those attributes using EAP, which is necessary i= n non-3gpp trusted access networks. > the document mentions PMIPv6 as one possible deployment choice in > Section 3.2 and that's all. >=20 > If you look at the call flow in Fig.1 there is no PMIPv6 at all. >=20 Not quite.. Please read the text underneath as well. : o WAC: WiFi Access Controller. In a PMIPv6-deployed network, could host the MAG functionality or is assumed to have a suitable interface to the MAG. In the following, we simply use "WAC" notation. The MAG functionality within the WAC (or within the WiFi access network), or a suitable interface to MAG is assumed for PMIPv6 deployments." So, either the MAG is the Authenticator (such as a NAS in your ID) or there is a trusted interface between the Authenticator and the MAG which has access to the EAP messages. In the next version, I will revise Figure 1 to show this explicitly. > The main purpose of this document seems to be to define four new EAP > attributes to be sent by the Mobile Node in 802.1X based > authentication exchanges over Wi-Fi links. >=20 Nope.. It is to re-use an existing and required protocol (EAP-AKA') to provide certain functions for WiFi integration (with PMIP6 nodes), which ar= e lacking today. > All these bring a lot of questions to one's mind: >=20 > 1. Given that the draft wants to define NEW EAP attributes to be sent by = MN, >=20 > it is clearly extending MN. >=20 > This seems to be so obvious. >=20 Again, this is about making PMIP6 work in trusted WiFi integration. The draft is defining EAP attributes for EAP Attributes registry. These attributes are necessary for the functioning of trusted WiFi PMIP6 deployments. Regards, -Rajeev > So the question is: can Netext work on such documents? The charter > clearly states that proxy mobility is based on network proxying the MN > so that we don't change MN? >=20 > Is this acceptable to the chairs? >=20 > Is this acceptable to WG? >=20 > Is this acceptable to IESG? I have cc'ed to Brian. >=20 > 2. As I said above, the draft's main concern is MN authentication on > Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links > and Wi-Fi link is a shared link. > Does this raise any concerns to you? >=20 > 3. This one is procedural. What about the charter? The current charter > talks about Localized Routing, Bulk Refresh and LMA Redirection and > logical interface. I could not see defining new EAP attributes in the > charter? >=20 > Kind regards, >=20 > Behcet >=20 > PS. I wanted to bring to the attention the concerns I personally have. > No offense to anyone, please. >=20 > On Mon, Apr 23, 2012 at 1:23 PM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Network-Based Mobility >> Extensions Working Group of the IETF. >>=20 >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : EAP Attributes for WiFi - EPC Integration >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Ravi Valmikam >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rajeev Koodli >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-wifi-epc-eap-attributes-00.tx= t >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-23 >>=20 >> =A0 With WiFi beginning to establishing itself as a trusted access >> =A0 network for service providers, it has become important to provide >> =A0 functions commonly available in 3G and 4G networks in WiFi access >> =A0 networks. =A0Such functions include Access Point Name (APN) Selection, >> =A0 multiple Packet Data Network (PDN) connections and seamless mobility >> =A0 between WiFi and 3G/4G networks. >>=20 >> =A0 EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >> =A0 authentication protocol for trusted access networks. =A0This IETF >> =A0 specification is required for mobile devices to access the 3GPP >> =A0 Evolved Packet Core (EPC) networks. =A0This document defines a few new >> =A0 EAP attributes and procedures to provide the above-mentioned >> =A0 functions in trusted WiFi access networks. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attri= butes >> -00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attrib= utes- >> 00.txt >>=20 >> _______________________________________________ >> 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 sarikaya2012@gmail.com Wed Apr 25 15:39:43 2012 Return-Path: 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 405E821F8811 for ; Wed, 25 Apr 2012 15:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, J_BACKHAIR_33=1, RCVD_IN_DNSWL_LOW=-1] 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 PM0g3GsZy6be for ; Wed, 25 Apr 2012 15:39:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 587BD21F8534 for ; Wed, 25 Apr 2012 15:39:42 -0700 (PDT) Received: by iazz13 with SMTP id z13so788385iaz.31 for ; Wed, 25 Apr 2012 15:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=tr0IcPUjAHdamETvGKoXBd5DN4Gz+EdVUIR116UwSVI=; b=0O+Iw/siUUGVlUvevpOfAzVJis0HsBO2LAiVJg0xzC9NaJuZvJ/gxMO1sEzYBf/XQd R9dJBYV6hBh/ri9jw8nqjdE9ae5+/WZq/SDQR6vKDkxOJOwiUpNf1RTfoyStvikQUa81 OJ/OK0S9F0Hlq013PVJ1Ahx1ZSnAspU44uiFH0IgaqI0BEztY2z/ljmhLmzqSXNXwrIh ssFuIomjBVtl64ADf8mpXYFRorP/UaHzHWVy0KZvQP2CiwX46ObhtPSBp2oDP3u9hqBf VNSD8eGa3gixJfu95vxYVzYyT0ZzbSzjI5HpCS72RrDOt4N/u/G4EoKspFoqV4V73jkl IBDg== MIME-Version: 1.0 Received: by 10.42.161.5 with SMTP id r5mr3477189icx.53.1335393581890; Wed, 25 Apr 2012 15:39:41 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Wed, 25 Apr 2012 15:39:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 17:39:41 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 25 Apr 2012 22:39:43 -0000 Hi Rajeev, draft-ietf-netext-radius-pmip6 DOES NOT extend MN. None of the attributes defined are sent by MN. Regards, Behcet On Wed, Apr 25, 2012 at 3:01 PM, wrote: > > Response inline: > > On 4/25/12 10:40 AM, "ext Behcet Sarikaya" wrote= : > >>Hi Basavaraj, chairs, > > Please note that I am the sole chair responsible for this I-D (as > mentioned in a previous email as well to the list). > >> >>I read this document and have some questions on it: >> >>The draft is on defining 4 new EAP attributes and how to use them. >> >>PMIPv6 relevance is very tangential, > > It is very much relevant. The use case has been presented quite clearly. > Given the lack of MN-MAG signaling at L3, the MN/UE cannot provide > indications such as Choice of APN (relevant in the 3GP context) or HO > indication to a MAG. By adding these attributes to EAP signaling an MN ca= n > accomplish this task. The MN needs to authenticate with the access networ= k > to which it attaches and this information can be signaled to the AN/MAG a= t > the time of attachment. > >> >> the document mentions PMIPv6 as one possible deployment choice in >>Section 3.2 and that's all. > > The I-D can elaborate further on how it ties in with PMIP6 for further > clarification if needed. > >> >>If you look at the call flow in Fig.1 there is no PMIPv6 at all. > > Right. That is because the APN choice and HO indication happens prior to > PMIP6 signaling (BU/BA). This information is used subsequently by > MAG<->LMA signaling which can be shown in the figure if that helps. > >> >>The main purpose of this document seems to be to define four new EAP >>attributes to be sent by the Mobile Node in 802.1X based >>authentication exchanges over Wi-Fi links. >> >>All these bring a lot of questions to one's mind: >> >>1. Given that the draft wants to define NEW EAP attributes to be sent by >>MN, >> >> it is clearly extending MN. >> >>This seems to be so obvious. > > Yes. That is well understood. > >> >>So the question is: can Netext work on such documents? The charter >>clearly states that proxy mobility is based on network proxying the MN >>so that we don't change MN? > > We are extending EAP signaling with the attributes. This does not mean > that we are creating a new MN-MAG signaling protocol which is out of scop= e > of this WG. You are misinterpreting what is intended by the statement "No > changes to the MN w.r.t PMIP6". > >> >>Is this acceptable to the chairs? > > Yes. > >> >>Is this acceptable to WG? > > Consensus call was issued previously with no negative feedback. > >> >>Is this acceptable to IESG? I have cc'ed to Brian. > > Good. > >> >>2. As I said above, the draft's main concern is MN authentication on >>Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links >>and Wi-Fi link is a shared link. >>Does this raise any concerns to you? > > No. > >> >>3. This one is procedural. What about the charter? The current charter >>talks about Localized Routing, Bulk Refresh and LMA Redirection and >>logical interface. I could not see defining new EAP attributes in the >>charter? > > Charter also says: > "The NETEXT working group will > also act as the primary forum where new extensions on top of the Proxy > Mobile IPv6 protocol can be developed." > > This work item as well as Service Selection for Mobile IPv6 will be added > to the charter milestones. > > -Raj > >> >>Kind regards, >> >>Behcet >> >>PS. I wanted to bring to the attention the concerns I personally have. >>No offense to anyone, please. >> >>On Mon, Apr 23, 2012 at 1:23 PM, =A0 wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. This draft is a work item of the Network-Based Mobility >>>Extensions Working Group of the IETF. >>> >>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : EAP Attributes for WiFi - EP= C Integration >>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Ravi Valmikam >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rajeev Koodli >>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: >>>draft-ietf-netext-wifi-epc-eap-attributes-00.txt >>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 >>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-23 >>> >>> =A0 With WiFi beginning to establishing itself as a trusted access >>> =A0 network for service providers, it has become important to provide >>> =A0 functions commonly available in 3G and 4G networks in WiFi access >>> =A0 networks. =A0Such functions include Access Point Name (APN) Selecti= on, >>> =A0 multiple Packet Data Network (PDN) connections and seamless mobilit= y >>> =A0 between WiFi and 3G/4G networks. >>> >>> =A0 EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>> =A0 authentication protocol for trusted access networks. =A0This IETF >>> =A0 specification is required for mobile devices to access the 3GPP >>> =A0 Evolved Packet Core (EPC) networks. =A0This document defines a few = new >>> =A0 EAP attributes and procedures to provide the above-mentioned >>> =A0 functions in trusted WiFi access networks. >>> >>> >>> A URL for this Internet-Draft is: >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attri= b >>>utes-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> >>>ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attrib= u >>>tes-00.txt >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext > From sgundave@cisco.com Wed Apr 25 16:13:54 2012 Return-Path: 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 A396921F879F for ; Wed, 25 Apr 2012 16:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Yz4anPJigiUg for ; Wed, 25 Apr 2012 16:13:54 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id F1DC121F8777 for ; Wed, 25 Apr 2012 16:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1779; q=dns/txt; s=iport; t=1335395633; x=1336605233; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=sKNOgou62ulTJKnZkKFuXiaQBhQqlLTSOq5myXaMBSI=; b=HDyC2WHJaJftoLahVjd4YBt1oPTfGCjnPXIp15PNGJffs4tn+Kqn/FOZ hwHOI+0++2pwBCYmDVahKcTkXFf2+b/bjzGCMLaekzQjuuN/KvRgevI00 G0eT4KMaGjiAoQOwMT9iy08Hf8CzoLyXku7EwyGRMEa+CJjSCwO9dYCZG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADKEmE+rRDoG/2dsb2JhbABFsU6BB4IJAQEBAwESASkBQQ0BCIEdAQEEARIih2gEDJs3oBOQYASILzSNGIERjUSBaYMJ X-IronPort-AV: E=Sophos;i="4.75,483,1330905600"; d="scan'208";a="39073315" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 25 Apr 2012 23:13:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3PNDrtr018923; Wed, 25 Apr 2012 23:13:53 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 16:13:53 -0700 Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 23:13:53 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 25 Apr 2012 16:13:49 -0700 From: Sri Gundavelli To: , "netext@ietf.org" Message-ID: Thread-Topic: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 Thread-Index: Ac0jORJBcxcV3Khp6EezpP5Ptz+elw== In-Reply-To: <1328515089.3833.8.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 25 Apr 2012 23:13:53.0617 (UTC) FILETIME=[1501F410:01CD2339] Subject: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:13:54 -0000 Hi Carlos, Yokota-san, Marco, Pierrick, Ahmad & folks ... Thanks for all the review comments. Please let us know if there any comment= s missing. http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-04 Regards Sri On 2/5/12 11:58 PM, "Carlos Jes=FAs Bernardos Cano" wrote: > Hi, >=20 > Some additional comments after a quick review of the draft: >=20 > - Section 3.1: I think there is a problem with the references, because > it appears in thge text: "If the received Proxy Binding Update includes > the IP Traffic Offload Selector option Section 4". I guess it should > say: "If the received Proxy Binding Update includes the IP Traffic > Offload Selector option (Section 4)". There are more instances referring > to other sections. >=20 > - Section 4. The IPTS options has the field "TS Format", which resembles > the option defined in RFC 6089 for the traffic selector sub-option, and > in this way re-uses the binary TS defined for IPv4 in RFC 6088. However, > the draft defines a new IANA space for this "TS Format" field, which > might be a bit confusing. Can we just re-use RFC 6089 space (now it only > has three values reserved: "0" that should not be used, and "1" for > binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid some > redundancy that might lead to confusion. If we do that, the draft would > probably need to define a flag or something to catch what it is now done > by putting a "TS Format" equal to "0". >=20 > - By doing offloading, there are issues associated to handovers (if the > mobile node moves, any traffic that was being offloaded would need to be > restarted). I guess some text on that would be helfpul. >=20 > Hope this helps, >=20 > Carlos From sgundave@cisco.com Wed Apr 25 16:31:30 2012 Return-Path: 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 314BF21E808F for ; Wed, 25 Apr 2012 16:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.859 X-Spam-Level: X-Spam-Status: No, score=-9.859 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 8UbH0eJMOK27 for ; Wed, 25 Apr 2012 16:31:29 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 584AD21E808C for ; Wed, 25 Apr 2012 16:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5931; q=dns/txt; s=iport; t=1335396687; x=1336606287; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=6Qy0W1PkSv6ODsvD3iWUDQPjT0zPZ42RekD7Oq/POB8=; b=AH38qAJYriinkSTBg8YGkZIKEqxsHA+dmRxyHplD4j8NlaKmdb7ZwmlG DRIvNY0iAIeYfRkwy0LaCVUdsS7cLVRVJ6QTiRoM9usRa+yZxk8Aq0hoa ViKDTt26Gu8sL64Qmy9ZadnMW3n17kCb4XIJYs0niihna2D1vfUW0OYjc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOSImE+rRDoG/2dsb2JhbABFgkauCIEAgQeCCQEBAQMBAQEBDwEqMQkHDQEIbTABAQQBEgkZh2gEAQubMKARiWuGdQSIY40YjlWBaYMJ X-IronPort-AV: E=Sophos;i="4.75,483,1330905600"; d="scan'208,217";a="39075342" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 25 Apr 2012 23:31:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3PNVR1i025746; Wed, 25 Apr 2012 23:31:27 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 16:31:26 -0700 Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 23:31:26 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 25 Apr 2012 16:31:20 -0700 From: Sri Gundavelli To: Marco Liebsch , "netext@ietf.org" Message-ID: Thread-Topic: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt Thread-Index: Ac0BLrfJDA4oGJmRTXyJExWUxpScgQiDMzo1 In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D24D74992@DAPHNIS.office.hd> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3418216283_14406220" X-OriginalArrivalTime: 25 Apr 2012 23:31:26.0850 (UTC) FILETIME=[88C88E20:01CD233B] Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:31:30 -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_3418216283_14406220 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Folks: Please comment on this draft. Lot of efforts went in to this from all the Authors, please review and comment. http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt Regards Sri On 3/13/12 8:40 AM, "Marco Liebsch" wrote: > Please find an update of our draft about a QoS option for PMIP6 on the IETF > repository, which > addresses comments from last meeting. The current version includes more > details about the > proposed operation and QoS attributes. > > Marco > > Filename: draft-liebsch-netext-pmip6-qos > Revision: 01 > Title: Quality of Service Option for Proxy Mobile IPv6 > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 32 > Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > Abstract: > This specification defines a new mobility option that can be used by > the mobility entities in the Proxy Mobile IPv6 domain to exchange > Quality of Service parameters associated with a subscriber's IP > flows. Using the QoS option, the local mobility anchor and the > mobile access gateway can exchange available QoS attributes and > associated values. This enables QoS policing and labeling of packets > to enforce QoS differentiation on the path between the local mobility > anchor and the mobile access gateway. Furthermore, making QoS > parameters available on the MAG enables mapping these parameters to > QoS rules being specific to the access technology which operates > below the mobile access gateway. After such mapping, QoS rules can > be enforced on the access technology components, such as an IEEE > 802.11e Wireless LAN controller. > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --B_3418216283_14406220 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [netext] New Version Notification for draft-liebsch-netext-pmip6= -qos-01.txt Folks:

Please comment on this draft. Lot of efforts went in to this from all the A= uthors, please review and comment.

http= ://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt



Regards
Sri



On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Please find an update of our draft about a QoS o= ption for PMIP6 on the IETF repository, which
addresses comments from last meeting. The current version includes more det= ails about the
proposed operation and QoS attributes.
 
Marco
 
Filename:            = ;draft-liebsch-netext-pmip6-qos
Revision:            = ;  01
Title:            &n= bsp;         Quality of Service= Option for Proxy Mobile IPv6
Creation date:   2012-03-12
WG ID:            &n= bsp;     Individual Submission
Number of pages: 32
Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt
 
Abstract:
   This specification defines a new mobility option that can= be used by
   the mobility entities in the Proxy Mobile IPv6 domain to = exchange
   Quality of Service parameters associated with a subscribe= r&#39;s IP
   flows.  Using the QoS option, the local mobility anc= hor and the
   mobile access gateway can exchange available QoS attribut= es and
   associated values.  This enables QoS policing and la= beling of packets
   to enforce QoS differentiation on the path between the lo= cal mobility
   anchor and the mobile access gateway.  Furthermore, = making QoS
   parameters available on the MAG enables mapping these par= ameters to
   QoS rules being specific to the access technology which o= perates
   below the mobile access gateway.  After such mapping= , QoS rules can
   be enforced on the access technology components, such as = an IEEE
   802.11e Wireless LAN controller.
 
 

___________= ____________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org= /mailman/listinfo/netext
--B_3418216283_14406220-- From asmuhanna@gmail.com Wed Apr 25 16:37:13 2012 Return-Path: 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 14D6621E808F for ; Wed, 25 Apr 2012 16:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 7r7BELC5gwGg for ; Wed, 25 Apr 2012 16:37:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 824AD21E8082 for ; Wed, 25 Apr 2012 16:37:12 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so801435obb.31 for ; Wed, 25 Apr 2012 16:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=KLfYNE6tF0xgCd8+ai6o//O1LE3e9k+f2jsQgrJbNnI=; b=zPEk4G+kw8wQkMjigSOXiWjP8LEtzZ0lPWlsF0hbph39sPJphIz902ESAlgWRYA4bX 5phzIRrGw/f9p06BK1+EO3u7N3+A+thvN5KIHjVL5kkUAW/ySQHqzubW8G4FUPCBfaWu TPqKIRO6aCwFgCTTtnl0ocboebCeXHxorY4Z3dOmDmtH63NYP5hLrHcENtrY8AGcYi2W e+S/SPL2rg6sTsiNoVY2lt8FQefSqQnV5CKoMFXKxcZQkVHTaPlxTiIo2F9qEGFwsXRb zaAspredFliu0EOg7eMYo/gGD2AtbIRk/ravOOt6YIYPbwKIzzC+dgwxHd5Blb0cKPVE n3Fg== Received: by 10.182.207.10 with SMTP id ls10mr5897085obc.9.1335397032145; Wed, 25 Apr 2012 16:37:12 -0700 (PDT) Received: from [192.168.50.189] ([216.138.88.105]) by mx.google.com with ESMTPS id hh2sm1515054obb.1.2012.04.25.16.37.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 16:37:11 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <8FEDFF7B-B098-43C1-9466-27DED5EDDD3C@gmail.com> X-Mailer: iPhone Mail (9B179) From: Ahmad Muhanna Date: Wed, 25 Apr 2012 16:37:08 -0700 To: Sri Gundavelli Cc: "netext@ietf.org" Subject: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:37:13 -0000 Thanks Sri for the update. No further comments. Regards, Ahmad On Apr 25, 2012, at 4:13 PM, Sri Gundavelli wrote: > Hi Carlos, Yokota-san, Marco, Pierrick, Ahmad & folks ... >=20 > Thanks for all the review comments. Please let us know if there any commen= ts > missing. >=20 > http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-04 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > On 2/5/12 11:58 PM, "Carlos Jes=C3=BAs Bernardos Cano" w= rote: >=20 >> Hi, >>=20 >> Some additional comments after a quick review of the draft: >>=20 >> - Section 3.1: I think there is a problem with the references, because >> it appears in thge text: "If the received Proxy Binding Update includes >> the IP Traffic Offload Selector option Section 4". I guess it should >> say: "If the received Proxy Binding Update includes the IP Traffic >> Offload Selector option (Section 4)". There are more instances referring >> to other sections. >>=20 >> - Section 4. The IPTS options has the field "TS Format", which resembles >> the option defined in RFC 6089 for the traffic selector sub-option, and >> in this way re-uses the binary TS defined for IPv4 in RFC 6088. However, >> the draft defines a new IANA space for this "TS Format" field, which >> might be a bit confusing. Can we just re-use RFC 6089 space (now it only >> has three values reserved: "0" that should not be used, and "1" for >> binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid some >> redundancy that might lead to confusion. If we do that, the draft would >> probably need to define a flag or something to catch what it is now done >> by putting a "TS Format" equal to "0". >>=20 >> - By doing offloading, there are issues associated to handovers (if the >> mobile node moves, any traffic that was being offloaded would need to be >> restarted). I guess some text on that would be helfpul. >>=20 >> Hope this helps, >>=20 >> Carlos >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From pierrick.seite@orange.com Thu Apr 26 01:03:21 2012 Return-Path: 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 B116821F860E for ; Thu, 26 Apr 2012 01:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38M+58u499GZ for ; Thu, 26 Apr 2012 01:03:20 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BE21F85FC for ; Thu, 26 Apr 2012 01:03:20 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFE4C1074001; Thu, 26 Apr 2012 10:03:17 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id D7EDFE301A1; Thu, 26 Apr 2012 10:03:17 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 10:03:18 +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: Thu, 26 Apr 2012 10:03:17 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202520BEC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 Thread-Index: Ac0jORJBcxcV3Khp6EezpP5Ptz+elwAQ5TwA References: <1328515089.3833.8.camel@acorde.it.uc3m.es> From: To: , , X-OriginalArrivalTime: 26 Apr 2012 08:03:18.0671 (UTC) FILETIME=[0A7489F0:01CD2383] Subject: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:03:21 -0000 Hi Sri, Thanks for the update. I've no further comments. Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la > part de Sri Gundavelli > Envoy=E9=A0: jeudi 26 avril 2012 01:14 > =C0=A0: cjbc@it.uc3m.es; netext@ietf.org > Objet=A0: Re: [netext] Review of = draft-ietf-netext-pmipv6-sipto-option-03 >=20 > Hi Carlos, Yokota-san, Marco, Pierrick, Ahmad & folks ... >=20 > Thanks for all the review comments. Please let us know if there any > comments > missing. >=20 > http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-04 >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > On 2/5/12 11:58 PM, "Carlos Jes=FAs Bernardos Cano" > wrote: >=20 > > Hi, > > > > Some additional comments after a quick review of the draft: > > > > - Section 3.1: I think there is a problem with the references, > because > > it appears in thge text: "If the received Proxy Binding Update > includes > > the IP Traffic Offload Selector option Section 4". I guess it should > > say: "If the received Proxy Binding Update includes the IP Traffic > > Offload Selector option (Section 4)". There are more instances > referring > > to other sections. > > > > - Section 4. The IPTS options has the field "TS Format", which > resembles > > the option defined in RFC 6089 for the traffic selector sub-option, > and > > in this way re-uses the binary TS defined for IPv4 in RFC 6088. > However, > > the draft defines a new IANA space for this "TS Format" field, which > > might be a bit confusing. Can we just re-use RFC 6089 space (now it > only > > has three values reserved: "0" that should not be used, and "1" for > > binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid > some > > redundancy that might lead to confusion. If we do that, the draft > would > > probably need to define a flag or something to catch what it is now > done > > by putting a "TS Format" equal to "0". > > > > - By doing offloading, there are issues associated to handovers (if > the > > mobile node moves, any traffic that was being offloaded would need = to > be > > restarted). I guess some text on that would be helfpul. > > > > Hope this helps, > > > > Carlos >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jouni.nospam@gmail.com Thu Apr 26 02:23:41 2012 Return-Path: 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 E5FAE21F873D for ; Thu, 26 Apr 2012 02:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 nDjWC1EM3mHH for ; Thu, 26 Apr 2012 02:23:40 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40C4521F85C6 for ; Thu, 26 Apr 2012 02:23:40 -0700 (PDT) Received: by bkuw5 with SMTP id w5so882133bku.31 for ; Thu, 26 Apr 2012 02:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MIIL1g16j3F+DeXTi1S15Dhhx8Xxj1GjlSqbWL2Bq/o=; b=uSGZxjpO1mvlvgJjjDuBR5NIQZ3F1CcPVi84uuQo3lRElSrKT0cxTszrzj4bOC14a4 ms+hxN+jngqQxapmmLNv73KZ0KmYhtBxrsVAjiE4mpE6PSOIuDuot/OmIo7JSYHFzXRY e/oGEGazY7LnlbQLudg5bWV7HC7MPDCPGnxEfFnXLrE1iIy8o2nYIReqFWc7lZRyhfIw JD+c04zXl6XitXqU5DE8bADWFvE6Gqrq3jOSpslKhkAM2pJL1BXBj7XWyfQUqRXxJ6r/ adb0GjMZrbbkUWrIZYQ6OAJInkC66mDxZn+Q6/qBkIOmsO43xwpGXk3f5Vj1muEIH1Oq PW1Q== Received: by 10.204.128.152 with SMTP id k24mr1823850bks.127.1335432219255; Thu, 26 Apr 2012 02:23:39 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id c5sm4201406bkw.7.2012.04.26.02.23.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 02:23:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 26 Apr 2012 12:23:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: netext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:23:42 -0000 Hi, Few initial comments on the WG draft.=20 o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead of RFC4187. o Both RFC4187 and RFC 5448 are Informational, thus why this draft aims to Standards Track? IMHO it should also be Informational. o Should the draft state it updates RFC5448? - Jouni On Apr 20, 2012, at 10:20 PM, = wrote: >=20 > Hello, >=20 > I have not heard any negative views on adopting this I-D. > I do believe that this I-D provides a good solution to the problem of > indicating APN choice (in 3GPP networks) or handover indication = (general > applicability) to the MAG via EAP signaling. >=20 > Hence it makes sense to adopt this I-D as a WG document and progress = it as > a Proposed Standard. >=20 > I believe APN selection and Handover indication attributes within EAP > messages are useful. I am not yet convinced about the multiple APN > connectivity attribute. Hence I would recommend publishing this I-D as = a > WG doc with the scope limited to these two attributes. >=20 > I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >=20 >=20 > -Raj >=20 > this I-D>=20 >=20 > On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" > wrote: >=20 >>=20 >> Hello, >>=20 >> At IETF83 the WG discussed the I-D : >> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >> for WiFi - EPC Integration) >>=20 >> This I-D proposes the use of EAP attributes as a means of signaling = to >> the MAG by an MN the parameters such as: >> 1. Choice of APN >> 2. Handover indication >> 3. Multiple APN connectivity >>=20 >> These attributes are relevant in the context of an MN connecting via = a >> WiFi network to the 3GPP evolved packet core (EPC). >>=20 >> The discussion in the WG favored using EAP attributes for parameters >> (1) and (2) above. The multiple APN connectivity problem is harder to >> solve.=20 >>=20 >> Question to the WG members: >> Should we adopt I-D = draft-valmikam-eap-attributes-wifi-epc-integration >> as a Netext WG document with the intent of standardizing the = following >> two attributes only : (1) Choice of APN and (2) Handover indication, = to be >> carried in EAP signaling at the time of network access = authentication? >>=20 >> Please respond to the ML (or to me privately) if you favor the = adoption >> of this I-D or are opposed to it. >>=20 >> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>=20 >> Yes [ ] >>=20 >> No [ ] >>=20 >> -Basavaraj >>=20 >> ---------------------------------------------------- >>=20 >> Abstract >>=20 >> With WiFi beginning to establishing itself as a trusted access >> network for service providers, it has become important to provide >> functions commonly available in 3G and 4G networks in WiFi access >> networks. Such functions include Access Point Name (APN) Selection, >> multiple Packet Data Network (PDN) connections and seamless mobility >> between WiFi and 3G/4G networks. >>=20 >> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >> authentication protocol for trusted access networks. This IETF >> specification is required for mobile devices to access the 3GPP >> Evolved Packet Core (EPC) networks. This document defines a few new >> EAP attributes and procedures to provide the above-mentioned >> functions in trusted WiFi access networks. >>=20 >>=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu Apr 26 04:39:41 2012 Return-Path: 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 DFEC121F8805 for ; Thu, 26 Apr 2012 04:39:41 -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 HIopu6d5SmE5 for ; Thu, 26 Apr 2012 04:39:41 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id EC15521F87F9 for ; Thu, 26 Apr 2012 04:39:40 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3QBdc0D006290; Thu, 26 Apr 2012 14:39:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 14:39:37 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Thu, 26 Apr 2012 13:39:31 +0200 From: To: Thread-Topic: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: AQHNEQ1ZU4UsKDirLE6Xqr8rotLyqJajvfoAgAkazID//9H6AIAAAEoA Date: Thu, 26 Apr 2012 11:39:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [96.226.49.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <940AC3EACAF0254598D66E684B9CC4E9@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2012 11:39:37.0846 (UTC) FILETIME=[42A57960:01CD23A1] X-Nokia-AV: Clean Subject: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 11:39:42 -0000 Hi Jouni, The I-D proposes new attributes to be carried in EAP signaling. I believe it is not specific to any individual EAP method. Hence it is applicable to multiple EAP methods that may be used for access authentication. References to EAP-AKA' should be mentioned as an example IMO. Since the I-D proposes new attributes to be carried in EAP, I do not believe it can be Informational. Hence the reason for the PS status proposal. -Raj On 4/26/12 4:23 AM, "ext jouni korhonen" wrote: > >> >>Hi, >> >>Few initial comments on the WG draft. >> >>o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead >> of RFC4187. >>o Both RFC4187 and RFC 5448 are Informational, thus why this draft >> aims to Standards Track? IMHO it should also be Informational. >>o Should the draft state it updates RFC5448? >> >>- Jouni >> >> >> >>On Apr 20, 2012, at 10:20 PM, >> wrote: >> >>>=20 >>> Hello, >>>=20 >>> I have not heard any negative views on adopting this I-D. >>> I do believe that this I-D provides a good solution to the problem of >>> indicating APN choice (in 3GPP networks) or handover indication >>>(general >>> applicability) to the MAG via EAP signaling. >>>=20 >>> Hence it makes sense to adopt this I-D as a WG document and progress it >>>as >>> a Proposed Standard. >>>=20 >>> I believe APN selection and Handover indication attributes within EAP >>> messages are useful. I am not yet convinced about the multiple APN >>> connectivity attribute. Hence I would recommend publishing this I-D as >>>a >>> WG doc with the scope limited to these two attributes. >>>=20 >>> I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >>>=20 >>>=20 >>> -Raj >>>=20 >>> >> this I-D>=20 >>>=20 >>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >>> wrote: >>>=20 >>>>=20 >>>> Hello, >>>>=20 >>>> At IETF83 the WG discussed the I-D : >>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>>> for WiFi - EPC Integration) >>>>=20 >>>> This I-D proposes the use of EAP attributes as a means of signaling to >>>> the MAG by an MN the parameters such as: >>>> 1. Choice of APN >>>> 2. Handover indication >>>> 3. Multiple APN connectivity >>>>=20 >>>> These attributes are relevant in the context of an MN connecting via a >>>> WiFi network to the 3GPP evolved packet core (EPC). >>>>=20 >>>> The discussion in the WG favored using EAP attributes for parameters >>>> (1) and (2) above. The multiple APN connectivity problem is harder to >>>> solve.=20 >>>>=20 >>>> Question to the WG members: >>>> Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration >>>> as a Netext WG document with the intent of standardizing the following >>>> two attributes only : (1) Choice of APN and (2) Handover indication, >>>>to be >>>> carried in EAP signaling at the time of network access authentication? >>>>=20 >>>> Please respond to the ML (or to me privately) if you favor the >>>>adoption >>>> of this I-D or are opposed to it. >>>>=20 >>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>>>=20 >>>> Yes [ ] >>>>=20 >>>> No [ ] >>>>=20 >>>> -Basavaraj >>>>=20 >>>> ---------------------------------------------------- >>>>=20 >>>> Abstract >>>>=20 >>>> With WiFi beginning to establishing itself as a trusted access >>>> network for service providers, it has become important to provide >>>> functions commonly available in 3G and 4G networks in WiFi access >>>> networks. Such functions include Access Point Name (APN) Selection, >>>> multiple Packet Data Network (PDN) connections and seamless mobility >>>> between WiFi and 3G/4G networks. >>>>=20 >>>> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>>> authentication protocol for trusted access networks. This IETF >>>> specification is required for mobile devices to access the 3GPP >>>> Evolved Packet Core (EPC) networks. This document defines a few new >>>> EAP attributes and procedures to provide the above-mentioned >>>> functions in trusted WiFi access networks. >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> > From brian@innovationslab.net Thu Apr 26 07:01:16 2012 Return-Path: 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 84BF921E8063 for ; Thu, 26 Apr 2012 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, 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 2iLggwoH6lhg for ; Thu, 26 Apr 2012 07:01:15 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id CF44421F8425 for ; Thu, 26 Apr 2012 07:01:15 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A2AEF88151 for ; Thu, 26 Apr 2012 07:01:15 -0700 (PDT) Received: from clemson.wireless.jhu.edu (unknown [128.220.159.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6FCF0130017 for ; Thu, 26 Apr 2012 07:01:15 -0700 (PDT) Message-ID: <4F99552D.5040604@innovationslab.net> Date: Thu, 26 Apr 2012 10:01:17 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netext] Milestone update for NetExt WG 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:01:16 -0000 The revised milestone dates look fine. When you submit them to the secretariat, make sure you indicate which ones can be marked "Done". Regards, Brian On 4/25/12 4:36 PM, Basavaraj.Patil@nokia.com wrote: > > Hi Brian, > > The milestones for the Netext WG are outdated and hence we would like to > propose revising the same. Please see the proposal below. Let me know if I > should submit the same to the IESG secretary. > > -Chairs > > > As of: Apr 25, 2012: > > Goals and Milestones > > Done WG chartered > Done Initial WG draft on Bulk Refresh > Done Decision on the inclusion of possible additional work items > Done Initial WG draft on LMA Redirection > Done Initial WG draft on Localized Routing Problem Statement > Mar 2010 Submit Bulk Refresh to IESG for publication as a Proposed > Standard RFC > Mar 2010 Submit LMA Redirection to IESG for publication as a Proposed > Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > May 2010 Submit Localized Routing Problem Statement to IESG for > publication as an Informational RFC > May 2010 Initial WG draft on Localized Routing Solution > Jul 2010 Initial WG document on Applicability Statement on > Logical Interface over Multiple Physical Interfaces > Jul 2010 WG decision on what Proxy Mobile IPv6 mechanisms are > needed to support flow mobility and inter-access handovers on a > logical interface over multiple physical interfaces > Oct 2010 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 > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a > Proposed Standard > Dec 2010 Submit Applicability Statement on Logical Interface over Multiple > Physical Interfaces to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Flow > Mobility and Inter-access Handovers on a Logical Interface over > Multiple Physical Interfaces for publication as Proposed Standard > RFC(s) > Feb 2011 Submit Localized Routing Solution to IESG for > publication as a Proposed Standard RFC > > ------------------------------------------------------------ > > A few of the delivereables that have been completed (or close to > completion): > > 1. Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy > Mobile IPv6 has been published as RFC6463 > 2. Bulk Binding Update Support for Proxy Mobile IPv6 > is in the RFC editors > queue > 3. RADIUS Support for Proxy Mobile IPv6 > is in the RFC editors queue > 4. Localized Routing for Proxy Mobile IPv6 > has completed IETF LC and IESG DISCUSSES are being dealt with by > the editor. > > Revised set of milestones for the WG below: > > Apr 2012 Initial WG document on Service Selection for MIP6 and > PMIP6 > Apr 2012 Initial WG document on EAP Attributes for WiFi - EPC Integration > Apr 2012 Submit Access Network Identifier (ANI) Option for > PMIP6 to IESG for publication as a proposed standard > Jul 2012 Submit Prefix Delegation for Proxy Mobile IPv6 to IESG > for publication as a proposed standard > Nov 2012 Submit IPv4 Traffic Offload Selector Option for Proxy > Mobile IPv6 to IESG for publication as a proposed > standard > Feb 2013 Submit Proxy Mobile IPv6 Extensions to Support Flow > Mobility to IESG for publication as a proposed > standard > Mar 2013 Submit Service Selection for MIP6 and PMIP6 to the > IESG for publication as a proposed standard > Apr 2013 Submit Logical Interface Support for multi-mode IP > Hosts for publication as an Informational document > May 2013 Submit EAP Attributes for WiFi - EPC Integration to > IESG for publication as a proposed standard > > From sarikaya2012@gmail.com Thu Apr 26 07:49:02 2012 Return-Path: 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 096FC21F867A for ; Thu, 26 Apr 2012 07:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZyYtoulzGAF8 for ; Thu, 26 Apr 2012 07:49:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 752C921F866E for ; Thu, 26 Apr 2012 07:49:00 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1112944ghb.31 for ; Thu, 26 Apr 2012 07:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=IsBZuWmc76Y2d2j2aVCt5ykHKyJsDfhdrde1Ba68Pus=; b=psmUciouF3KKQzVXBL6mSFk446kFxuiWFTXZNNEHNHRHuxAtdah58tRfojIRV9M+sO PHXTYGRIVrfHL37EtW5PckHH77/jfKbj56kWtCuhMQwFWnLhjfkduzc4trsYQs8OacBR VxUa6XE2F33uu32YkA3JflhRwEDl1FlPBzwl2Jk/DQww/2aahr31D9IUFOsgo1r0uKBC Rhp0ugV3gBhpPEhPnxXij284GPE070LX1qKuHleKwYLp/nTyO1Tbu/ErtkALExelwdqM 4Ukd5hbj10MfWzQ3QenKL9/bzdiKUGBdy0yDvkjYd4oRP8paBxKriMGW/hShvyWvxZVM jtTQ== MIME-Version: 1.0 Received: by 10.50.47.135 with SMTP id d7mr18796758ign.66.1335451739697; Thu, 26 Apr 2012 07:48:59 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Thu, 26 Apr 2012 07:48:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Apr 2012 09:48:59 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 26 Apr 2012 14:49:02 -0000 Hi Basavaraj, I think that Jouni is absolutely right. This draft wishes basically to update RFC5448, it should be called rfc5448bis (and of course informational). RFC5448 was developed in EAP WG, now there is EAP Method Update (emu) WG. It think this work belongs to emu, IMHO. Regards, Behcet On Thu, Apr 26, 2012 at 6:39 AM, wrote: > > > Hi Jouni, > > > The I-D proposes new attributes to be carried in EAP signaling. I believe > it is not specific to any individual EAP method. > Hence it is applicable to multiple EAP methods that may be used for acces= s > authentication. > References to EAP-AKA' should be mentioned as an example IMO. > > Since the I-D proposes new attributes to be carried in EAP, I do not > believe it can be Informational. Hence the reason for the PS status > proposal. > > > -Raj > > On 4/26/12 4:23 AM, "ext jouni korhonen" wrote: >> >>> >>>Hi, >>> >>>Few initial comments on the WG draft. >>> >>>o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead >>> =A0of RFC4187. >>>o Both RFC4187 and RFC 5448 are Informational, thus why this draft >>> =A0aims to Standards Track? IMHO it should also be Informational. >>>o Should the draft state it updates RFC5448? >>> >>>- Jouni >>> >>> >>> >>>On Apr 20, 2012, at 10:20 PM, >>> wrote: >>> >>>> >>>> Hello, >>>> >>>> I have not heard any negative views on adopting this I-D. >>>> I do believe that this I-D provides a good solution to the problem of >>>> indicating APN choice (in 3GPP networks) or handover indication >>>>(general >>>> applicability) to the MAG via EAP signaling. >>>> >>>> Hence it makes sense to adopt this I-D as a WG document and progress i= t >>>>as >>>> a Proposed Standard. >>>> >>>> I believe APN selection and Handover indication attributes within EAP >>>> messages are useful. I am not yet convinced about the multiple APN >>>> connectivity attribute. Hence I would recommend publishing this I-D as >>>>a >>>> WG doc with the scope limited to these two attributes. >>>> >>>> I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >>>> >>>> >>>> -Raj >>>> >>>> >>> this I-D> >>>> >>>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >>>> wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> At IETF83 the WG discussed the I-D : >>>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>>>> for WiFi - EPC Integration) >>>>> >>>>> This I-D proposes the use of EAP attributes as a means of signaling t= o >>>>> the MAG by an MN the parameters such as: >>>>> 1. Choice of APN >>>>> 2. Handover indication >>>>> 3. Multiple APN connectivity >>>>> >>>>> These attributes are relevant in the context of an MN connecting via = a >>>>> WiFi network to the 3GPP evolved packet core (EPC). >>>>> >>>>> The discussion in the WG favored using EAP attributes for parameters >>>>> (1) and (2) above. The multiple APN connectivity problem is harder to >>>>> solve. >>>>> >>>>> Question to the WG members: >>>>> Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integratio= n >>>>> as a Netext WG document with the intent of standardizing the followin= g >>>>> two attributes only : (1) Choice of APN and (2) Handover indication, >>>>>to be >>>>> carried in EAP signaling at the time of network access authentication= ? >>>>> >>>>> Please respond to the ML (or to me privately) if you favor the >>>>>adoption >>>>> of this I-D or are opposed to it. >>>>> >>>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>>>> >>>>> Yes [ =A0] >>>>> >>>>> No =A0[ =A0] >>>>> >>>>> -Basavaraj >>>>> >>>>> ---------------------------------------------------- >>>>> >>>>> Abstract >>>>> >>>>> =A0With WiFi beginning to establishing itself as a trusted access >>>>> =A0network for service providers, it has become important to provide >>>>> =A0functions commonly available in 3G and 4G networks in WiFi access >>>>> =A0networks. =A0Such functions include Access Point Name (APN) Select= ion, >>>>> =A0multiple Packet Data Network (PDN) connections and seamless mobili= ty >>>>> =A0between WiFi and 3G/4G networks. >>>>> >>>>> =A0EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>>>> =A0authentication protocol for trusted access networks. =A0This IETF >>>>> =A0specification is required for mobile devices to access the 3GPP >>>>> =A0Evolved Packet Core (EPC) networks. =A0This document defines a few= new >>>>> =A0EAP attributes and procedures to provide the above-mentioned >>>>> =A0functions in trusted WiFi access networks. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 sarikaya2012@gmail.com Thu Apr 26 07:59:15 2012 Return-Path: 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 7CA0F21F86EC for ; Thu, 26 Apr 2012 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gpqKYv81fJTA for ; Thu, 26 Apr 2012 07:59:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 062D921F86E5 for ; Thu, 26 Apr 2012 07:59:14 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1125557ghb.31 for ; Thu, 26 Apr 2012 07:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6E+GO5a+dHZ/ftZIpwOUSH1L458MxIzG+S71qJWEhKU=; b=BIG6/ePlbvA881OTWLIcVycRJCnh0XsduKpe6XNLAwsjo4lJsVfxvXlhyYjJifsat7 wnCVMONPJeRQ4LhpjYWy1NlssJdaeKF+2QM6sKae7M5EoDkHZmHbQv7W9JSel71XHbK+ jK2nf+bGecVifVXjDTYvQnIWbRLr3FDa3p8CnynqqbfOYlPucb7qWRIgcNvEbVWFT9z3 WgrZdegZKa8w+ucJC53nqX4/A7u26qQmnv72lYZsZrwJ701Nku9//RyrAOFC0ETV5q3X dxbziUIreSYzA6dQED4NMaGnCxSTTe9JdAe/oio5nOtduK45BpooTzQ9gGW8gqX/twxF ieiA== MIME-Version: 1.0 Received: by 10.50.47.135 with SMTP id d7mr18848413ign.66.1335452354354; Thu, 26 Apr 2012 07:59:14 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Thu, 26 Apr 2012 07:59:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Apr 2012 09:59:14 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 26 Apr 2012 14:59:15 -0000 Hi Basavaraj, >>2. As I said above, the draft's main concern is MN authentication on >>Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links >>and Wi-Fi link is a shared link. >>Does this raise any concerns to you? > > No. Really? Imagine MAG as defined in RFC 5213 (which assumes that each MN is on a point-to-point link) is connected to a shared link. I think the result will be disastrous. If there is only one MN, it may be OK but as more MNs join, especially in hot spots then the problems start. So you can not be serious. Regards, Behcet From rkoodli@cisco.com Thu Apr 26 08:01:41 2012 Return-Path: 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 0592611E809A for ; Thu, 26 Apr 2012 08:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.366 X-Spam-Level: X-Spam-Status: No, score=-110.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 oH09-GYFZwSS for ; Thu, 26 Apr 2012 08:01:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFD621F86FD for ; Thu, 26 Apr 2012 08:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=4265; q=dns/txt; s=iport; t=1335452500; x=1336662100; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=oQKEo4frG/ZoJpGTbI6RTS2/JbrM2cvLTsmRFloVlMc=; b=XS/eCAFiw/eDMWYmpT1TVFxT89shdzA03EGP7M9C7L/c7KTQEGYIhDYo sX35OovCoIUHLl0rY2aUqbemk7JQjY8sZ4xT7NhgQKQxzAYv3EnSF+jK6 9LsLCqO1kSMAcs7i4+NXXSgbWmhPYQx4ifGcLHNeXXvNXEBng0H3PD/9M s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN5imU+tJV2a/2dsb2JhbABEsWuBB4IJAQEBAwEBAQEPAScCASoHEA0BCBhPBjABAQQBEhsHh10DBgULmmKWUA2JTwSKAnuFaASIY40aiz2DGoFpgwiBNA X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78078026" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2012 15:01:40 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QF1diS026063; Thu, 26 Apr 2012 15:01:39 GMT Received: from xmb-rcd-214.cisco.com ([72.163.62.221]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 10:00:22 -0500 Received: from 10.21.147.13 ([10.21.147.13]) by XMB-RCD-214.cisco.com ([72.163.62.221]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Apr 2012 15:00:22 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 26 Apr 2012 08:05:43 -0700 From: Rajeev Koodli To: jouni korhonen , Message-ID: Thread-Topic: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: Ac0jvgzarqvr/0TVgUGtwZT8RBBPmA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Apr 2012 15:00:22.0505 (UTC) FILETIME=[4DD29590:01CD23BD] Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:01:41 -0000 Hi Jouni, Thanks for the input. On 4/26/12 2:23 AM, "jouni korhonen" wrote: > > o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead > of RFC4187. I believe since the EAP attributes registry is the same, the same attributes should also be applicable to EAP-SIM/AKA/AKA'. > o Both RFC4187 and RFC 5448 are Informational, thus why this draft > aims to Standards Track? IMHO it should also be Informational. I think the attribute definition should be PS, no? > o Should the draft state it updates RFC5448? > I do not believe it needs to. I will consult Jari on this. -Rajeev > - Jouni > > > > On Apr 20, 2012, at 10:20 PM, > wrote: > >> >> Hello, >> >> I have not heard any negative views on adopting this I-D. >> I do believe that this I-D provides a good solution to the problem of >> indicating APN choice (in 3GPP networks) or handover indication (general >> applicability) to the MAG via EAP signaling. >> >> Hence it makes sense to adopt this I-D as a WG document and progress it as >> a Proposed Standard. >> >> I believe APN selection and Handover indication attributes within EAP >> messages are useful. I am not yet convinced about the multiple APN >> connectivity attribute. Hence I would recommend publishing this I-D as a >> WG doc with the scope limited to these two attributes. >> >> I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >> >> >> -Raj >> >> > this I-D> >> >> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >> wrote: >> >>> >>> Hello, >>> >>> At IETF83 the WG discussed the I-D : >>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>> for WiFi - EPC Integration) >>> >>> This I-D proposes the use of EAP attributes as a means of signaling to >>> the MAG by an MN the parameters such as: >>> 1. Choice of APN >>> 2. Handover indication >>> 3. Multiple APN connectivity >>> >>> These attributes are relevant in the context of an MN connecting via a >>> WiFi network to the 3GPP evolved packet core (EPC). >>> >>> The discussion in the WG favored using EAP attributes for parameters >>> (1) and (2) above. The multiple APN connectivity problem is harder to >>> solve. >>> >>> Question to the WG members: >>> Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration >>> as a Netext WG document with the intent of standardizing the following >>> two attributes only : (1) Choice of APN and (2) Handover indication, to be >>> carried in EAP signaling at the time of network access authentication? >>> >>> Please respond to the ML (or to me privately) if you favor the adoption >>> of this I-D or are opposed to it. >>> >>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>> >>> Yes [ ] >>> >>> No [ ] >>> >>> -Basavaraj >>> >>> ---------------------------------------------------- >>> >>> Abstract >>> >>> With WiFi beginning to establishing itself as a trusted access >>> network for service providers, it has become important to provide >>> functions commonly available in 3G and 4G networks in WiFi access >>> networks. Such functions include Access Point Name (APN) Selection, >>> multiple Packet Data Network (PDN) connections and seamless mobility >>> between WiFi and 3G/4G networks. >>> >>> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>> authentication protocol for trusted access networks. This IETF >>> specification is required for mobile devices to access the 3GPP >>> Evolved Packet Core (EPC) networks. This document defines a few new >>> EAP attributes and procedures to provide the above-mentioned >>> functions in trusted WiFi access networks. >>> >>> >> >> _______________________________________________ >> 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 jouni.nospam@gmail.com Thu Apr 26 08:16:51 2012 Return-Path: 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 116DE21E8028 for ; Thu, 26 Apr 2012 08:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 OkkN6CxV5-jO for ; Thu, 26 Apr 2012 08:16:49 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8821F86F9 for ; Thu, 26 Apr 2012 08:16:48 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so879621wgb.13 for ; Thu, 26 Apr 2012 08:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=HzYwE5hJqvZKzhbdX5iGj8CuAPlZJDyRGCMMwhYYdWc=; b=NNuaEd7qSaLNnaPVKOi1Sld6imvFf3iVSt2E5S3u54mtbDkKyQoJ36pdWsxezUn1FC 0IwKdJCemAiouSuo87QozGuoCUV/o0rj/gT8FXGghVRAi4rrrrx9ZW025+eIJd6dNlAm qCIY4KelJiaYntpmrtUndxRFb8lchFrn/+gPhWKQNOHDRSAb+nhqtO9K+Wqscs0jeqmp xKh+iSp6+SM30JMMY8bts50MCdmVs/ways71Df9tIam8TKb4kIXjsrMORSynL5jCaypx XNASHL7qbn/jrcv42yP6/PVHd8N9f/Y5lcK5rFSbo+YTPnrOSJZPh0Hjds/QmUphSIRS s2dw== Received: by 10.180.80.104 with SMTP id q8mr5231684wix.14.1335453408159; Thu, 26 Apr 2012 08:16:48 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id du4sm148942wib.10.2012.04.26.08.16.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 08:16:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: <025953A7-6018-43B8-A9C3-79A940AAC2DF@gmail.com> Date: Thu, 26 Apr 2012 18:16:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8723D5F4-BC8C-473E-B719-23920A0CDBF0@gmail.com> References: <025953A7-6018-43B8-A9C3-79A940AAC2DF@gmail.com> To: netext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:16:51 -0000 Resending.. it seems I managed to goof with my postings again ;) - Jouni On Apr 26, 2012, at 2:38 PM, = wrote: >=20 > Hi Jouni, >=20 > > The I-D proposes new attributes to be carried in EAP signaling. I = believe > it is not specific to any individual EAP method. This solution is specific to EAP-AKA/AKA' as it reads now. It does not work on a random EAP-method. > Hence it is applicable to multiple EAP methods that may be used for = access > authentication. Only if that method is SIM/AKA/AKA'. > References to EAP-AKA' should be mentioned as an example IMO. >=20 > Since the I-D proposes new attributes to be carried in EAP, I do not > believe it can be Informational. Hence the reason for the PS status > proposal. I disagree. Attributes in this draft are method specific. This also implies the IANA considerations should point to a specific registry. - Jouni >=20 >>=20 >> >>=20 >> -Raj >>=20 >> On 4/26/12 4:23 AM, "ext jouni korhonen" = wrote: >>=20 >>>=20 >>> Hi, >>>=20 >>> Few initial comments on the WG draft. >>>=20 >>> o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 = instead >>> of RFC4187. >>> o Both RFC4187 and RFC 5448 are Informational, thus why this draft >>> aims to Standards Track? IMHO it should also be Informational. >>> o Should the draft state it updates RFC5448? >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>> On Apr 20, 2012, at 10:20 PM, >>> wrote: >>>=20 >>>>=20 >>>> Hello, >>>>=20 >>>> I have not heard any negative views on adopting this I-D. >>>> I do believe that this I-D provides a good solution to the problem = of >>>> indicating APN choice (in 3GPP networks) or handover indication = (general >>>> applicability) to the MAG via EAP signaling. >>>>=20 >>>> Hence it makes sense to adopt this I-D as a WG document and = progress it >>>> as >>>> a Proposed Standard. >>>>=20 >>>> I believe APN selection and Handover indication attributes within = EAP >>>> messages are useful. I am not yet convinced about the multiple APN >>>> connectivity attribute. Hence I would recommend publishing this I-D = as a >>>> WG doc with the scope limited to these two attributes. >>>>=20 >>>> I-D Authors, please go ahead and publish the I-D as a Netext WG = doc. >>>>=20 >>>>=20 >>>> -Raj >>>>=20 >>>> >>> this I-D>=20 >>>>=20 >>>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >>>> wrote: >>>>=20 >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> At IETF83 the WG discussed the I-D : >>>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>>>> for WiFi - EPC Integration) >>>>>=20 >>>>> This I-D proposes the use of EAP attributes as a means of = signaling to >>>>> the MAG by an MN the parameters such as: >>>>> 1. Choice of APN >>>>> 2. Handover indication >>>>> 3. Multiple APN connectivity >>>>>=20 >>>>> These attributes are relevant in the context of an MN connecting = via a >>>>> WiFi network to the 3GPP evolved packet core (EPC). >>>>>=20 >>>>> The discussion in the WG favored using EAP attributes for = parameters >>>>> (1) and (2) above. The multiple APN connectivity problem is harder = to >>>>> solve.=20 >>>>>=20 >>>>> Question to the WG members: >>>>> Should we adopt I-D = draft-valmikam-eap-attributes-wifi-epc-integration >>>>> as a Netext WG document with the intent of standardizing the = following >>>>> two attributes only : (1) Choice of APN and (2) Handover = indication, >>>>> to be >>>>> carried in EAP signaling at the time of network access = authentication? >>>>>=20 >>>>> Please respond to the ML (or to me privately) if you favor the = adoption >>>>> of this I-D or are opposed to it. >>>>>=20 >>>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>>>>=20 >>>>> Yes [ ] >>>>>=20 >>>>> No [ ] >>>>>=20 >>>>> -Basavaraj >>>>>=20 >>>>> ---------------------------------------------------- >>>>>=20 >>>>> Abstract >>>>>=20 >>>>> With WiFi beginning to establishing itself as a trusted access >>>>> network for service providers, it has become important to provide >>>>> functions commonly available in 3G and 4G networks in WiFi access >>>>> networks. Such functions include Access Point Name (APN) = Selection, >>>>> multiple Packet Data Network (PDN) connections and seamless = mobility >>>>> between WiFi and 3G/4G networks. >>>>>=20 >>>>> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>>>> authentication protocol for trusted access networks. This IETF >>>>> specification is required for mobile devices to access the 3GPP >>>>> Evolved Packet Core (EPC) networks. This document defines a few = new >>>>> EAP attributes and procedures to provide the above-mentioned >>>>> functions in trusted WiFi access networks. >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >>=20 >=20 From jouni.nospam@gmail.com Thu Apr 26 08:30:46 2012 Return-Path: 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 CCB4321E80B5 for ; Thu, 26 Apr 2012 08:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 xsMhwWg4qXUS for ; Thu, 26 Apr 2012 08:30:45 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED0E21E80B3 for ; Thu, 26 Apr 2012 08:30:45 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1078465wib.13 for ; Thu, 26 Apr 2012 08:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FJ95vFEUU7kSWm8DQQeDOniB2tDUVvUz2WOdPMeZ/bw=; b=X7D5LgpoLWQPYjtNl1c2jKyKl8hTM0XfbnpNJvAKUIw+RQ5MwJazwQdC0iwPMIbgjk 25KYm7RPqo5o0l9C+RkuE87RbvAlUvb6GvJx0mrRMih9g5Y/bH8ctGefNQwh36yUjjVD +3JUFPRGX6qyHY/JsKIaYa7wbsKPMGdg12B7ThZO0BWu7UKQYGsvNw9Gn20JCXjXPzZJ zheZUWGgp+Y/es085XkUUaBkUAXvDqbo1SMOwkPeEY42z6SE5rkC5XcYQFaeWYYfkFwq i2+V0+PqYHTHxDw6haUqYmTjnYj6rbBgIJ/erE8rrrmbai9DkUFkUMgnOnKCTzAJOXKL Srww== Received: by 10.180.107.101 with SMTP id hb5mr17487663wib.7.1335454244497; Thu, 26 Apr 2012 08:30:44 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id fl2sm12074590wib.2.2012.04.26.08.30.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 08:30:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 26 Apr 2012 18:30:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8DD78E66-79BE-4190-9E35-136F9B32BF6C@gmail.com> References: To: Rajeev Koodli X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:30:46 -0000 Hi Rajeev, On Apr 26, 2012, at 6:05 PM, Rajeev Koodli wrote: >=20 > Hi Jouni, >=20 > Thanks for the input. >=20 > On 4/26/12 2:23 AM, "jouni korhonen" wrote: >=20 >>=20 >> o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 = instead >> of RFC4187. >=20 > I believe since the EAP attributes registry is the same, the same = attributes > should also be applicable to EAP-SIM/AKA/AKA'. The registry is the same, sure. What I mean, is that RFC5448 also needs to be reference since it is specifically mentioned in the draft. Just nitpicking.. >> o Both RFC4187 and RFC 5448 are Informational, thus why this draft >> aims to Standards Track? IMHO it should also be Informational. >=20 > I think the attribute definition should be PS, no? No.. furthermore, the IANA registry for EAP-SIM/AKA/AKA' attributes is specification required, which means any publicly available document fulfills the requirement for a specification. Even a vendor product spec would suffice. Personally, I rather have an RFC than something = else.. >>=20 >> o Should the draft state it updates RFC5448? >>=20 >=20 > I do not believe it needs to. I will consult Jari on this. Ack. - JOuni >=20 > -Rajeev >=20 >=20 >=20 >> - Jouni >>=20 >>=20 >>=20 >> On Apr 20, 2012, at 10:20 PM, >> wrote: >>=20 >>>=20 >>> Hello, >>>=20 >>> I have not heard any negative views on adopting this I-D. >>> I do believe that this I-D provides a good solution to the problem = of >>> indicating APN choice (in 3GPP networks) or handover indication = (general >>> applicability) to the MAG via EAP signaling. >>>=20 >>> Hence it makes sense to adopt this I-D as a WG document and progress = it as >>> a Proposed Standard. >>>=20 >>> I believe APN selection and Handover indication attributes within = EAP >>> messages are useful. I am not yet convinced about the multiple APN >>> connectivity attribute. Hence I would recommend publishing this I-D = as a >>> WG doc with the scope limited to these two attributes. >>>=20 >>> I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >>>=20 >>>=20 >>> -Raj >>>=20 >>> >> this I-D>=20 >>>=20 >>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >>> wrote: >>>=20 >>>>=20 >>>> Hello, >>>>=20 >>>> At IETF83 the WG discussed the I-D : >>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>>> for WiFi - EPC Integration) >>>>=20 >>>> This I-D proposes the use of EAP attributes as a means of signaling = to >>>> the MAG by an MN the parameters such as: >>>> 1. Choice of APN >>>> 2. Handover indication >>>> 3. Multiple APN connectivity >>>>=20 >>>> These attributes are relevant in the context of an MN connecting = via a >>>> WiFi network to the 3GPP evolved packet core (EPC). >>>>=20 >>>> The discussion in the WG favored using EAP attributes for = parameters >>>> (1) and (2) above. The multiple APN connectivity problem is harder = to >>>> solve.=20 >>>>=20 >>>> Question to the WG members: >>>> Should we adopt I-D = draft-valmikam-eap-attributes-wifi-epc-integration >>>> as a Netext WG document with the intent of standardizing the = following >>>> two attributes only : (1) Choice of APN and (2) Handover = indication, to be >>>> carried in EAP signaling at the time of network access = authentication? >>>>=20 >>>> Please respond to the ML (or to me privately) if you favor the = adoption >>>> of this I-D or are opposed to it. >>>>=20 >>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>>>=20 >>>> Yes [ ] >>>>=20 >>>> No [ ] >>>>=20 >>>> -Basavaraj >>>>=20 >>>> ---------------------------------------------------- >>>>=20 >>>> Abstract >>>>=20 >>>> With WiFi beginning to establishing itself as a trusted access >>>> network for service providers, it has become important to provide >>>> functions commonly available in 3G and 4G networks in WiFi access >>>> networks. Such functions include Access Point Name (APN) = Selection, >>>> multiple Packet Data Network (PDN) connections and seamless = mobility >>>> between WiFi and 3G/4G networks. >>>>=20 >>>> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>>> authentication protocol for trusted access networks. This IETF >>>> specification is required for mobile devices to access the 3GPP >>>> Evolved Packet Core (EPC) networks. This document defines a few = new >>>> EAP attributes and procedures to provide the above-mentioned >>>> functions in trusted WiFi access networks. >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 From jouni.nospam@gmail.com Thu Apr 26 08:40:59 2012 Return-Path: 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 9F5A521E80DF for ; Thu, 26 Apr 2012 08:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 euxBFap9eA1e for ; Thu, 26 Apr 2012 08:40:59 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE4DA21F86BE for ; Thu, 26 Apr 2012 08:40:58 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so5082415wib.13 for ; Thu, 26 Apr 2012 08:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=75EIkhTAGfyVgImqhjbn7VQT4z/b1PVkUH2QbiTFlgA=; b=TQVyFqvhQDDtPaOPgDNbIU1riUbmeQXEdcUd+ElytWFfZ/DggECyUf9U9tFGhYGQIb aenbh0m44dZGsdu7IAKs26oSBH0rUEuP0DPS6PLhPa20gjAoopLSkS1JqnWXpVnWP3AA D3U7k4VpgCT+r5SSd8vjfeM7pXEjd4NsOGgLR/SN9gN9O1ozk2I1X7aYK5TUviZqHot4 YLodrVRyUF+GqLpP4og0nCn4T2xz0we84f38lhxbDVxv7BXKGA8WNLFG8KaMET9Om2Qu MuEwJx33TZk6cwMGVjxG0Zda/su7SF6JCj413t9Z68algZT+N1UA6r3sefVQb3GJmAF8 2J+g== Received: by 10.216.134.19 with SMTP id r19mr3205244wei.66.1335454857769; Thu, 26 Apr 2012 08:40:57 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id l5sm45456641wia.11.2012.04.26.08.40.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 08:40:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 26 Apr 2012 18:40:51 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org Subject: Re: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:40:59 -0000 On Apr 26, 2012, at 5:48 PM, Behcet Sarikaya wrote: > It think this work belongs to emu, IMHO. I would say currently in IETF, Netext definitely has the best knowledge on the problem space this draft tackles. - Jouni From Basavaraj.Patil@nokia.com Thu Apr 26 08:44:20 2012 Return-Path: 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 74C8F21F86B1 for ; Thu, 26 Apr 2012 08:44:20 -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 e1zLEsukW7k7 for ; Thu, 26 Apr 2012 08:44:19 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2067721E80BB for ; Thu, 26 Apr 2012 08:44:18 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3QFiFKp003909; Thu, 26 Apr 2012 18:44:16 +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); Thu, 26 Apr 2012 18:44:15 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Thu, 26 Apr 2012 17:44:15 +0200 From: To: Thread-Topic: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt Thread-Index: AQHNIvmxXoE5SUVh4EqssCBV4/H4f5argS0AgAGRogD//7jDAA== Date: Thu, 26 Apr 2012 15:44:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [96.226.49.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <8CC76C17D1CF144AA698C8A0E0032C82@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2012 15:44:15.0568 (UTC) FILETIME=[6F401D00:01CD23C3] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:44:20 -0000 Inline: On 4/26/12 9:59 AM, "ext Behcet Sarikaya" wrote: >Hi Basavaraj, > >>>2. As I said above, the draft's main concern is MN authentication on >>>Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links >>>and Wi-Fi link is a shared link. >>>Does this raise any concerns to you? >> >> No. > >Really? > >Imagine MAG as defined in RFC 5213 (which assumes that each MN is on a >point-to-point link) is connected to a shared link. We all understand the link model requirements for PMIP6. Nothing is being changed there.=20 >I think the result will be disastrous. Why? Can you elaborate? > If there is only one MN, it may >be OK but as more MNs join, especially in hot spots then the problems >start. Why? Are you saying that the current link model for PMIP6 allows only a single MN to attach to a WiFi AP (as an example)? What is the basis for saying that having many MNs attach to a MAG in a hotspot (assuming wifi) will result in problems? Is there any work that you have done to make such a statement? -Raj > > >So you can not be serious. > >Regards, > >Behcet From Basavaraj.Patil@nokia.com Thu Apr 26 08:50:49 2012 Return-Path: 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 5DE7921E80FC for ; Thu, 26 Apr 2012 08:50:49 -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 2t9PD+yILUEk for ; Thu, 26 Apr 2012 08:50:48 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4610F21E80FB for ; Thu, 26 Apr 2012 08:50:48 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3QFogLi008721; Thu, 26 Apr 2012 18:50:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 18:50:44 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Thu, 26 Apr 2012 17:50:43 +0200 From: To: Thread-Topic: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: AQHNI7yjAUL1FzJqt0Sqo6Z3q46Z3Jasy9yA Date: Thu, 26 Apr 2012 15:50:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [96.226.49.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2012 15:50:44.0103 (UTC) FILETIME=[56D5D970:01CD23C4] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:50:49 -0000 Inline: On 4/26/12 9:48 AM, "ext Behcet Sarikaya" wrote: >Hi Basavaraj, > >I think that Jouni is absolutely right. > >This draft wishes basically to update RFC5448, it should be called >rfc5448bis (and of course informational). RFC5448 was developed in EAP >WG, now there is EAP Method Update (emu) WG. This I-D is not proposing an update to the EAP method itself. It is adding an additional set of attributes to the EAP messages. Since this is not an EAP method update, I do not believe we need to take this to the EMU WG. Of course we will engage with the EMU WG to ensure that experts review the I-D and are aware of it as it goes through the process. The I-D is specifically adding attributes that assist a MAG in determining of the HO flag needs to be set or in determining which LMA to send the BU to (based on the APN attribute). Hence it is very much PMIP6 and Netext WG centric. -Raj > >It think this work belongs to emu, IMHO. > >Regards, > >Behcet > >On Thu, Apr 26, 2012 at 6:39 AM, wrote: >> >> >> Hi Jouni, >> >> >> The I-D proposes new attributes to be carried in EAP signaling. I >>believe >> it is not specific to any individual EAP method. >> Hence it is applicable to multiple EAP methods that may be used for >>access >> authentication. >> References to EAP-AKA' should be mentioned as an example IMO. >> >> Since the I-D proposes new attributes to be carried in EAP, I do not >> believe it can be Informational. Hence the reason for the PS status >> proposal. >> >> >> -Raj >> >> On 4/26/12 4:23 AM, "ext jouni korhonen" wrote: >>> >>>> >>>>Hi, >>>> >>>>Few initial comments on the WG draft. >>>> >>>>o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead >>>> of RFC4187. >>>>o Both RFC4187 and RFC 5448 are Informational, thus why this draft >>>> aims to Standards Track? IMHO it should also be Informational. >>>>o Should the draft state it updates RFC5448? >>>> >>>>- Jouni >>>> >>>> >>>> >>>>On Apr 20, 2012, at 10:20 PM, >>>> wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> I have not heard any negative views on adopting this I-D. >>>>> I do believe that this I-D provides a good solution to the problem of >>>>> indicating APN choice (in 3GPP networks) or handover indication >>>>>(general >>>>> applicability) to the MAG via EAP signaling. >>>>> >>>>> Hence it makes sense to adopt this I-D as a WG document and progress >>>>>it >>>>>as >>>>> a Proposed Standard. >>>>> >>>>> I believe APN selection and Handover indication attributes within EAP >>>>> messages are useful. I am not yet convinced about the multiple APN >>>>> connectivity attribute. Hence I would recommend publishing this I-D >>>>>as >>>>>a >>>>> WG doc with the scope limited to these two attributes. >>>>> >>>>> I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >>>>> >>>>> >>>>> -Raj >>>>> >>>>> >>>>w.r.t >>>>> this I-D> >>>>> >>>>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >>>>> wrote: >>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> At IETF83 the WG discussed the I-D : >>>>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>>>>> for WiFi - EPC Integration) >>>>>> >>>>>> This I-D proposes the use of EAP attributes as a means of signaling >>>>>>to >>>>>> the MAG by an MN the parameters such as: >>>>>> 1. Choice of APN >>>>>> 2. Handover indication >>>>>> 3. Multiple APN connectivity >>>>>> >>>>>> These attributes are relevant in the context of an MN connecting >>>>>>via a >>>>>> WiFi network to the 3GPP evolved packet core (EPC). >>>>>> >>>>>> The discussion in the WG favored using EAP attributes for parameters >>>>>> (1) and (2) above. The multiple APN connectivity problem is harder >>>>>>to >>>>>> solve. >>>>>> >>>>>> Question to the WG members: >>>>>> Should we adopt I-D >>>>>>draft-valmikam-eap-attributes-wifi-epc-integration >>>>>> as a Netext WG document with the intent of standardizing the >>>>>>following >>>>>> two attributes only : (1) Choice of APN and (2) Handover indication, >>>>>>to be >>>>>> carried in EAP signaling at the time of network access >>>>>>authentication? >>>>>> >>>>>> Please respond to the ML (or to me privately) if you favor the >>>>>>adoption >>>>>> of this I-D or are opposed to it. >>>>>> >>>>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>>>>> >>>>>> Yes [ ] >>>>>> >>>>>> No [ ] >>>>>> >>>>>> -Basavaraj >>>>>> >>>>>> ---------------------------------------------------- >>>>>> >>>>>> Abstract >>>>>> >>>>>> With WiFi beginning to establishing itself as a trusted access >>>>>> network for service providers, it has become important to provide >>>>>> functions commonly available in 3G and 4G networks in WiFi access >>>>>> networks. Such functions include Access Point Name (APN) >>>>>>Selection, >>>>>> multiple Packet Data Network (PDN) connections and seamless >>>>>>mobility >>>>>> between WiFi and 3G/4G networks. >>>>>> >>>>>> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>>>>> authentication protocol for trusted access networks. This IETF >>>>>> specification is required for mobile devices to access the 3GPP >>>>>> Evolved Packet Core (EPC) networks. This document defines a few >>>>>>new >>>>>> EAP attributes and procedures to provide the above-mentioned >>>>>> functions in trusted WiFi access networks. >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Basavaraj.Patil@nokia.com Thu Apr 26 08:54:47 2012 Return-Path: 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 EE11121E8106 for ; Thu, 26 Apr 2012 08:54:47 -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 kYwxjTWTlz73 for ; Thu, 26 Apr 2012 08:54:47 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 32CB621E80FC for ; Thu, 26 Apr 2012 08:54:46 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3QFsgem017454; Thu, 26 Apr 2012 18:54:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 18:54:42 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Thu, 26 Apr 2012 17:54:36 +0200 From: To: Thread-Topic: Question about EAP method applicability.. Thread-Index: AQHNI8TgTOe3Cl3hpki519w/mfYVwQ== Date: Thu, 26 Apr 2012 15:54:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [96.226.49.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <290D98B629F2D9499E0616CD219C5E41@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2012 15:54:42.0774 (UTC) FILETIME=[E5182760:01CD23C4] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: [netext] Question about EAP method applicability.. 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:54:48 -0000 Hello, The I-D mentions EAP methods EAP-AKA/AKA'. Subsequent emails have also mentioned EAP-SIM. The above set of EAP methods are generally applicable in a 3GPP operator environment.=20 Question: Are these attributes also valid for example if the EAP method used is EAP-TLS or EAP-TTLS? It would make the applicability of these attributes wider if that is the case. -Raj From sgundave@cisco.com Thu Apr 26 09:32:47 2012 Return-Path: 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 635F121E80C9 for ; Thu, 26 Apr 2012 09:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 QIs2mxBzcgb4 for ; Thu, 26 Apr 2012 09:32:46 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA021E80C7 for ; Thu, 26 Apr 2012 09:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2727; q=dns/txt; s=iport; t=1335457966; x=1336667566; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=hILWq6o6jk12pEIl07wTcsaAqf5kTrxGoK3zbw/unSU=; b=a/oPhZFsP4ZmdauRbnhNNY/YJQJqEqxbDzNC0kU1iQ9sm38k2uVE3WRL 2ZMN3uaivFTX27lXCmOCjE+pbdIiW4/rQi+0FUWDweXY/+z1HpDdoQfUl tjrDf033jGOPlBLTCmI/P0KntMcHgYawAQuuflCSrAQNgAU4sr5wum/2D A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE94mU+rRDoJ/2dsb2JhbABEsWyBB4IJAQEBAwEBAQEPASkBMRANAQgYJy4fEQEBBAESIodmBAELmlOgLZBlBIgvNI0agRGNRoFpgwg X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="39177651" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 26 Apr 2012 16:32:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3QGWkrH032506; Thu, 26 Apr 2012 16:32:46 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 09:32:46 -0700 Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Apr 2012 16:32:45 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 26 Apr 2012 09:32:33 -0700 From: Sri Gundavelli To: , , Message-ID: Thread-Topic: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 Thread-Index: Ac0jORJBcxcV3Khp6EezpP5Ptz+elwAQ5TwAABNhxKY= In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202520BEC@ftrdmel0.rd.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 26 Apr 2012 16:32:46.0352 (UTC) FILETIME=[36368100:01CD23CA] Subject: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:32:47 -0000 Thanks every one.=20 Chairs: Please let us know if there are any open issues, or if its ready for WGLC. Regards Sri On 4/26/12 1:03 AM, "pierrick.seite@orange.com" wrote: > Hi Sri, >=20 > Thanks for the update. I've no further comments. >=20 > Pierrick >=20 >> -----Message d'origine----- >> De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la >> part de Sri Gundavelli >> Envoy=E9=A0: jeudi 26 avril 2012 01:14 >> =C0=A0: cjbc@it.uc3m.es; netext@ietf.org >> Objet=A0: Re: [netext] Review of draft-ietf-netext-pmipv6-sipto-option-03 >>=20 >> Hi Carlos, Yokota-san, Marco, Pierrick, Ahmad & folks ... >>=20 >> Thanks for all the review comments. Please let us know if there any >> comments >> missing. >>=20 >> http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-04 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >> On 2/5/12 11:58 PM, "Carlos Jes=FAs Bernardos Cano" >> wrote: >>=20 >>> Hi, >>>=20 >>> Some additional comments after a quick review of the draft: >>>=20 >>> - Section 3.1: I think there is a problem with the references, >> because >>> it appears in thge text: "If the received Proxy Binding Update >> includes >>> the IP Traffic Offload Selector option Section 4". I guess it should >>> say: "If the received Proxy Binding Update includes the IP Traffic >>> Offload Selector option (Section 4)". There are more instances >> referring >>> to other sections. >>>=20 >>> - Section 4. The IPTS options has the field "TS Format", which >> resembles >>> the option defined in RFC 6089 for the traffic selector sub-option, >> and >>> in this way re-uses the binary TS defined for IPv4 in RFC 6088. >> However, >>> the draft defines a new IANA space for this "TS Format" field, which >>> might be a bit confusing. Can we just re-use RFC 6089 space (now it >> only >>> has three values reserved: "0" that should not be used, and "1" for >>> binary TS IPv4, and "2" for binary TS IPv6)? I think we would avoid >> some >>> redundancy that might lead to confusion. If we do that, the draft >> would >>> probably need to define a flag or something to catch what it is now >> done >>> by putting a "TS Format" equal to "0". >>>=20 >>> - By doing offloading, there are issues associated to handovers (if >> the >>> mobile node moves, any traffic that was being offloaded would need to >> be >>> restarted). I guess some text on that would be helfpul. >>>=20 >>> Hope this helps, >>>=20 >>> Carlos >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Thu Apr 26 09:34:07 2012 Return-Path: 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 A625821E8133 for ; Thu, 26 Apr 2012 09:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.425 X-Spam-Level: X-Spam-Status: No, score=-110.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YE1EoG0aFZep for ; Thu, 26 Apr 2012 09:34:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A3DAF21E80C0 for ; Thu, 26 Apr 2012 09:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=4906; q=dns/txt; s=iport; t=1335458046; x=1336667646; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ifAG7qhK7P2Me8kamVKFXPUbgNh02MJSOX5b+XIvthg=; b=PP+b6sUyf8tvkozCcSdbzPwQ6P9pdKqd1a7wTr2oL13I+gatsg7ligMM 42sXcGlpGjsrFeuj55jdFvfWx62Q/J4Rnq9wtKK3ropGAcFJCe4KRObqL YgdfnmrBGc4gmi+ujli8eVHgQz3GEzlF1opLu0uleyJtU5GwOXTFIZZnD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJR4mU+tJXHA/2dsb2JhbABEsWyBB4IJAQEBBAEBAQ8BJwIBKgcLEgEIGE8GMAEBBA4FGweHXQMLC5pUlk0NiU8EigJ7hWgEiGONGos9gxqBaYMIgTQ X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78158299" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 26 Apr 2012 16:34:06 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3QGY6F8029966; Thu, 26 Apr 2012 16:34:06 GMT Received: from xmb-rcd-214.cisco.com ([72.163.62.221]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:34:05 -0500 Received: from 10.21.147.13 ([10.21.147.13]) by XMB-RCD-214.cisco.com ([72.163.62.221]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Apr 2012 16:34:05 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 26 Apr 2012 09:39:26 -0700 From: Rajeev Koodli To: jouni korhonen Message-ID: Thread-Topic: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: Ac0jyyRrCbdpMEMfY0yJhajb/I0ncw== In-Reply-To: <8DD78E66-79BE-4190-9E35-136F9B32BF6C@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Apr 2012 16:34:05.0904 (UTC) FILETIME=[65A12D00:01CD23CA] Cc: netext@ietf.org Subject: Re: [netext] Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:34:07 -0000 Hi, On 4/26/12 8:30 AM, "jouni korhonen" wrote: >> >> I believe since the EAP attributes registry is the same, the same attributes >> should also be applicable to EAP-SIM/AKA/AKA'. > > The registry is the same, sure. What I mean, is that RFC5448 also needs > to be reference since it is specifically mentioned in the draft. Just > nitpicking.. > No problem, will reference RFC5448. >> >> I think the attribute definition should be PS, no? > > No.. furthermore, the IANA registry for EAP-SIM/AKA/AKA' attributes > is specification required, which means any publicly available document > fulfills the requirement for a specification. Even a vendor product > spec would suffice. Personally, I rather have an RFC than something else.. > Agree we need an RFC to capture this so that PMIP6 can benefit in trusted WiFi deployments. -Rajeev >>> >>> o Should the draft state it updates RFC5448? >>> >> >> I do not believe it needs to. I will consult Jari on this. > > Ack. > > - JOuni > > >> >> -Rajeev >> >> >> >>> - Jouni >>> >>> >>> >>> On Apr 20, 2012, at 10:20 PM, >>> wrote: >>> >>>> >>>> Hello, >>>> >>>> I have not heard any negative views on adopting this I-D. >>>> I do believe that this I-D provides a good solution to the problem of >>>> indicating APN choice (in 3GPP networks) or handover indication (general >>>> applicability) to the MAG via EAP signaling. >>>> >>>> Hence it makes sense to adopt this I-D as a WG document and progress it as >>>> a Proposed Standard. >>>> >>>> I believe APN selection and Handover indication attributes within EAP >>>> messages are useful. I am not yet convinced about the multiple APN >>>> connectivity attribute. Hence I would recommend publishing this I-D as a >>>> WG doc with the scope limited to these two attributes. >>>> >>>> I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >>>> >>>> >>>> -Raj >>>> >>>> >>> this I-D> >>>> >>>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >>>> wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> At IETF83 the WG discussed the I-D : >>>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>>>> for WiFi - EPC Integration) >>>>> >>>>> This I-D proposes the use of EAP attributes as a means of signaling to >>>>> the MAG by an MN the parameters such as: >>>>> 1. Choice of APN >>>>> 2. Handover indication >>>>> 3. Multiple APN connectivity >>>>> >>>>> These attributes are relevant in the context of an MN connecting via a >>>>> WiFi network to the 3GPP evolved packet core (EPC). >>>>> >>>>> The discussion in the WG favored using EAP attributes for parameters >>>>> (1) and (2) above. The multiple APN connectivity problem is harder to >>>>> solve. >>>>> >>>>> Question to the WG members: >>>>> Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration >>>>> as a Netext WG document with the intent of standardizing the following >>>>> two attributes only : (1) Choice of APN and (2) Handover indication, to be >>>>> carried in EAP signaling at the time of network access authentication? >>>>> >>>>> Please respond to the ML (or to me privately) if you favor the adoption >>>>> of this I-D or are opposed to it. >>>>> >>>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>>>> >>>>> Yes [ ] >>>>> >>>>> No [ ] >>>>> >>>>> -Basavaraj >>>>> >>>>> ---------------------------------------------------- >>>>> >>>>> Abstract >>>>> >>>>> With WiFi beginning to establishing itself as a trusted access >>>>> network for service providers, it has become important to provide >>>>> functions commonly available in 3G and 4G networks in WiFi access >>>>> networks. Such functions include Access Point Name (APN) Selection, >>>>> multiple Packet Data Network (PDN) connections and seamless mobility >>>>> between WiFi and 3G/4G networks. >>>>> >>>>> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>>>> authentication protocol for trusted access networks. This IETF >>>>> specification is required for mobile devices to access the 3GPP >>>>> Evolved Packet Core (EPC) networks. This document defines a few new >>>>> EAP attributes and procedures to provide the above-mentioned >>>>> functions in trusted WiFi access networks. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 rkoodli@cisco.com Thu Apr 26 09:39:26 2012 Return-Path: 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 D239821E8138 for ; Thu, 26 Apr 2012 09:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 TtsjZkSHC-M4 for ; Thu, 26 Apr 2012 09:39:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C787F21E80B4 for ; Thu, 26 Apr 2012 09:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=6916; q=dns/txt; s=iport; t=1335458365; x=1336667965; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=kYit2aEZEV3kQkeSqbXk7pj+irOCMlJRRvNS9U+vc0A=; b=jjsxWpnPM4CT7FFElsv9qZWbReXEttLHMgD60bYBY7CBEM/JwBtGLW+m 5bzhzZElVgjh87PXdPlasDY8HDknYeJAG3ZshBIvGCK5znGlT3XgzQERM 2ECbUVcSEpX/HXVad82YWTRneVIj5PAYVIq/Q9O4NzVIgiKxTswVYJt4J Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOR5mU+tJV2Y/2dsb2JhbABEsWyBB4IJAQEBAwEBAQEPAScCASoEAwsSAQgYTwYnCQIEAQ0FGweHXQMGBQuaWZZNDYlPBIoCe4VoBIhjjRqLPYMagWmDCIE0 X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78161970" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 26 Apr 2012 16:39:25 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3QGdPs9021911; Thu, 26 Apr 2012 16:39:25 GMT Received: from xmb-rcd-214.cisco.com ([72.163.62.221]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:39:25 -0500 Received: from 10.21.147.13 ([10.21.147.13]) by XMB-RCD-214.cisco.com ([72.163.62.221]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Apr 2012 16:39:24 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 26 Apr 2012 09:44:45 -0700 From: Rajeev Koodli To: "Basavaraj.Patil@nokia.com" , Message-ID: Thread-Topic: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? Thread-Index: AQHNI7yjAUL1FzJqt0Sqo6Z3q46Z3Jasy9yAgACEb5Q= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Apr 2012 16:39:25.0166 (UTC) FILETIME=[23ECB0E0:01CD23CB] Cc: netext@ietf.org Subject: Re: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:39:26 -0000 The draft only defines EAP Attributes. These attributes affect the PMIP6 functioning in trusted WiFi environment. Treat this as EAP attributes for PMIP6, just as we have done Radius Attributes for PMIP6, in Netext. -Rajeev On 4/26/12 8:50 AM, "Basavaraj.Patil@nokia.com" wrote: > > Inline: > > On 4/26/12 9:48 AM, "ext Behcet Sarikaya" wrote: > >> Hi Basavaraj, >> >> I think that Jouni is absolutely right. >> >> This draft wishes basically to update RFC5448, it should be called >> rfc5448bis (and of course informational). RFC5448 was developed in EAP >> WG, now there is EAP Method Update (emu) WG. > > > This I-D is not proposing an update to the EAP method itself. It is adding > an additional set of attributes to the EAP messages. > Since this is not an EAP method update, I do not believe we need to take > this to the EMU WG. Of course we will engage with the EMU WG to ensure > that experts review the I-D and are aware of it as it goes through the > process. > > The I-D is specifically adding attributes that assist a MAG in determining > of the HO flag needs to be set or in determining which LMA to send the BU > to (based on the APN attribute). Hence it is very much PMIP6 and Netext WG > centric. > > -Raj > >> >> It think this work belongs to emu, IMHO. >> >> Regards, >> >> Behcet >> >> On Thu, Apr 26, 2012 at 6:39 AM, wrote: >>> >>> >>> Hi Jouni, >>> >>> >>> The I-D proposes new attributes to be carried in EAP signaling. I >>> believe >>> it is not specific to any individual EAP method. >>> Hence it is applicable to multiple EAP methods that may be used for >>> access >>> authentication. >>> References to EAP-AKA' should be mentioned as an example IMO. >>> >>> Since the I-D proposes new attributes to be carried in EAP, I do not >>> believe it can be Informational. Hence the reason for the PS status >>> proposal. >>> >>> >>> -Raj >>> >>> On 4/26/12 4:23 AM, "ext jouni korhonen" wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> Few initial comments on the WG draft. >>>>> >>>>> o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead >>>>> of RFC4187. >>>>> o Both RFC4187 and RFC 5448 are Informational, thus why this draft >>>>> aims to Standards Track? IMHO it should also be Informational. >>>>> o Should the draft state it updates RFC5448? >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> >>>>> On Apr 20, 2012, at 10:20 PM, >>>>> wrote: >>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> I have not heard any negative views on adopting this I-D. >>>>>> I do believe that this I-D provides a good solution to the problem of >>>>>> indicating APN choice (in 3GPP networks) or handover indication >>>>>> (general >>>>>> applicability) to the MAG via EAP signaling. >>>>>> >>>>>> Hence it makes sense to adopt this I-D as a WG document and progress >>>>>> it >>>>>> as >>>>>> a Proposed Standard. >>>>>> >>>>>> I believe APN selection and Handover indication attributes within EAP >>>>>> messages are useful. I am not yet convinced about the multiple APN >>>>>> connectivity attribute. Hence I would recommend publishing this I-D >>>>>> as >>>>>> a >>>>>> WG doc with the scope limited to these two attributes. >>>>>> >>>>>> I-D Authors, please go ahead and publish the I-D as a Netext WG doc. >>>>>> >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>> w.r.t >>>>>> this I-D> >>>>>> >>>>>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)" >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> At IETF83 the WG discussed the I-D : >>>>>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes >>>>>>> for WiFi - EPC Integration) >>>>>>> >>>>>>> This I-D proposes the use of EAP attributes as a means of signaling >>>>>>> to >>>>>>> the MAG by an MN the parameters such as: >>>>>>> 1. Choice of APN >>>>>>> 2. Handover indication >>>>>>> 3. Multiple APN connectivity >>>>>>> >>>>>>> These attributes are relevant in the context of an MN connecting >>>>>>> via a >>>>>>> WiFi network to the 3GPP evolved packet core (EPC). >>>>>>> >>>>>>> The discussion in the WG favored using EAP attributes for parameters >>>>>>> (1) and (2) above. The multiple APN connectivity problem is harder >>>>>>> to >>>>>>> solve. >>>>>>> >>>>>>> Question to the WG members: >>>>>>> Should we adopt I-D >>>>>>> draft-valmikam-eap-attributes-wifi-epc-integration >>>>>>> as a Netext WG document with the intent of standardizing the >>>>>>> following >>>>>>> two attributes only : (1) Choice of APN and (2) Handover indication, >>>>>>> to be >>>>>>> carried in EAP signaling at the time of network access >>>>>>> authentication? >>>>>>> >>>>>>> Please respond to the ML (or to me privately) if you favor the >>>>>>> adoption >>>>>>> of this I-D or are opposed to it. >>>>>>> >>>>>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration: >>>>>>> >>>>>>> Yes [ ] >>>>>>> >>>>>>> No [ ] >>>>>>> >>>>>>> -Basavaraj >>>>>>> >>>>>>> ---------------------------------------------------- >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> With WiFi beginning to establishing itself as a trusted access >>>>>>> network for service providers, it has become important to provide >>>>>>> functions commonly available in 3G and 4G networks in WiFi access >>>>>>> networks. Such functions include Access Point Name (APN) >>>>>>> Selection, >>>>>>> multiple Packet Data Network (PDN) connections and seamless >>>>>>> mobility >>>>>>> between WiFi and 3G/4G networks. >>>>>>> >>>>>>> EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access >>>>>>> authentication protocol for trusted access networks. This IETF >>>>>>> specification is required for mobile devices to access the 3GPP >>>>>>> Evolved Packet Core (EPC) networks. This document defines a few >>>>>>> new >>>>>>> EAP attributes and procedures to provide the above-mentioned >>>>>>> functions in trusted WiFi access networks. >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu Apr 26 12:04:47 2012 Return-Path: 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 2BA3721E8136 for ; Thu, 26 Apr 2012 12:04:47 -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 rgr5yrNVlDSZ for ; Thu, 26 Apr 2012 12:04:46 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2F85021E814A for ; Thu, 26 Apr 2012 12:04:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3QJ4gLO006196; Thu, 26 Apr 2012 22:04:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 22:04:42 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Thu, 26 Apr 2012 21:04:41 +0200 From: To: Thread-Topic: Question about standardizing new EAP attributes for use with Proxy MIP6 Thread-Index: AQHNI99vfpEwHj03qkG7aNOq+SreKQ== Date: Thu, 26 Apr 2012 19:04:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [96.226.49.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B213CECC011D843A61BE1B69A8924F8@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2012 19:04:42.0343 (UTC) FILETIME=[6FC45770:01CD23DF] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: [netext] Question about standardizing new EAP attributes for use with Proxy MIP6 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:04:47 -0000 Hello Joe/Alan, The Netext WG has taken up the I-D: draft-ietf-netext-wifi-epc-eap-attributes. This I-D proposes a few new EAP attributes that are applicable in a Proxy Mobile IPv6 environment. And more specifically for use in a 3GPP wifi deployment scenario. The proposed extensions are : 1. APN choice and 2. Handover indication Using these extensions an MN (Mobile Node) can provide indication to a MAG (Mobile Access Gateway) about its choice of APN or if the attachment should be viewed as a handover. These EAP attributes would be included by an MN when it performs EAP authentication (EAP-SIM/AKA/AKA'). We would like your feedback and comments about this I-D. We would also like to keep the EMU WG informed about this work since the expertise w.r.t EAP attributes and methods lies there. -Raj From denghui02@gmail.com Fri Apr 27 04:15:41 2012 Return-Path: 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 7B7B821F87FD for ; Fri, 27 Apr 2012 04:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.378 X-Spam-Level: X-Spam-Status: No, score=-103.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 DdoWIBFqoYpc for ; Fri, 27 Apr 2012 04:15:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 638BE21F878E for ; Fri, 27 Apr 2012 04:15:40 -0700 (PDT) Received: by yenm5 with SMTP id m5so305123yen.31 for ; Fri, 27 Apr 2012 04:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=RACGqiNwK0mnYHGP6TR5FRtCxvTuYLbuPsx1WoZBzxg=; b=jSphz7HhOy/WE42GR4I3rz0WN37f7jTSq1y/Jsm51OX1h8E5YNx2KXtCgbP/clugrr Xr8qbS+QLX5V37k4ofvs7siIAL/rYExymbaL/R833aUgmjO5jgZmOz1UCwi2na4Aulun b/NwlhGK/0BGOiwLCAILAIUfcFjBjn+DRDVR1BI4I/txpTSeFHM/Kp4vLQ6I/R8OY5Jy M4v5qRdthZDij1/8vRqkkIPkuZ4ZnJqn+jFmfulccJvgH/MI/226O0MkgdCaIlRWcpo9 9oaIvqvMAfMIflBqEHYpaKNthsp66iJYuFq4+r1nnwQem8VD/Pa54HHXnH1U1MaNIig5 7A4g== MIME-Version: 1.0 Received: by 10.236.125.234 with SMTP id z70mr10649066yhh.18.1335525339896; Fri, 27 Apr 2012 04:15:39 -0700 (PDT) Received: by 10.147.115.6 with HTTP; Fri, 27 Apr 2012 04:15:39 -0700 (PDT) Date: Fri, 27 Apr 2012 19:15:39 +0800 Message-ID: From: Hui Deng To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=485b397dd071791bcb04bea73985 Subject: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:15:41 -0000 --485b397dd071791bcb04bea73985 Content-Type: text/plain; charset=ISO-8859-1 Hello authors, I have read through document, want to clarify below: In the section 6, many parameters related to 3GPP air-interface has been spcified like ARP, GDBR, GUBR, because wifi today doesn't have such capability, just wan to know whether you would like to extend WLC capability to support and make wifi a much better wireless technology:) If PMIP6 historically doesn't QoS, is that PCC will not be able to use for PMIP6 based S5/S8 interfaces? thanks for writing this document. Best, -Hui 2012/4/26 Sri Gundavelli > Folks: > > Please comment on this draft. Lot of efforts went in to this from all the > Authors, please review and comment. > > http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > > > Regards > Sri > > > > > On 3/13/12 8:40 AM, "Marco Liebsch" wrote: > > Please find an update of our draft about a QoS option for PMIP6 on the > IETF repository, which > addresses comments from last meeting. The current version includes more > details about the > proposed operation and QoS attributes. > > Marco > > Filename: draft-liebsch-netext-pmip6-qos > Revision: 01 > Title: Quality of Service Option for Proxy Mobile IPv6 > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 32 > Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > Abstract: > This specification defines a new mobility option that can be used by > the mobility entities in the Proxy Mobile IPv6 domain to exchange > Quality of Service parameters associated with a subscriber's IP > flows. Using the QoS option, the local mobility anchor and the > mobile access gateway can exchange available QoS attributes and > associated values. This enables QoS policing and labeling of packets > to enforce QoS differentiation on the path between the local mobility > anchor and the mobile access gateway. Furthermore, making QoS > parameters available on the MAG enables mapping these parameters to > QoS rules being specific to the access technology which operates > below the mobile access gateway. After such mapping, QoS rules can > be enforced on the access technology components, such as an IEEE > 802.11e Wireless LAN controller. > > > > ------------------------------ > _______________________________________________ > 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 > > --485b397dd071791bcb04bea73985 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello authors,
=A0
I have read through document, want to clarify be= low:
=A0
In the section 6, many parameters related to 3GP= P air-interface has been spcified like ARP, GDBR, GUBR,
because wifi today doesn't have such capabil= ity, just wan to know whether you would like to extend WLC capability
to support and make wifi a much better wireless = technology:)
=A0
If PMIP6 historically doesn't QoS, is that P= CC will not be able to use for PMIP6 based S5/S8 interfaces?
=A0
thanks for writing this=A0document.
=A0
Best,
=A0
-Hui

2012/4/26 Sri Gundavelli <<= a href=3D"mailto:sgundave@cisco.com" target=3D"_blank">sgundave@cisco.com>
Folks:

Please comment on this draft. Lot of efforts went = in to this from all the Authors, please review and comment.

http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt


Regards
Sri=20




On 3/13/12 8:40 AM, "Marco Liebsch&q= uot; <Marco= .Liebsch@neclab.eu> wrote:
Please find an update of our draft about a QoS option for= PMIP6 on the IETF repository, which
addresses comments from last meetin= g. The current version includes more details about the
proposed operatio= n and QoS attributes.
=A0
Marco
=A0
Filename: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0draft-lie= bsch-netext-pmip6-qos
Revision: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A00= 1
Title: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Quality of Service Option for Proxy Mobile IPv6
Creation date: =A0=A0201= 2-03-12
WG ID: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Indivi= dual Submission
Number of pages: 32
Link: http://www.ietf.org/id/draft-l= iebsch-netext-pmip6-qos-01.txt
=A0
Abstract:
=A0=A0=A0This spe= cification defines a new mobility option that can be used by
=A0=A0=A0the mobility entities in the Proxy Mobile IPv6 domain to exchange<= br>=A0=A0=A0Quality of Service parameters associated with a subscriber&= #39;s IP
=A0=A0=A0flows. =A0Using the QoS option, the local mobility anc= hor and the
=A0=A0=A0mobile access gateway can exchange available QoS at= tributes and
=A0=A0=A0associated values. =A0This enables QoS policing and labeling of pa= ckets
=A0=A0=A0to enforce QoS differentiation on the path between the lo= cal mobility
=A0=A0=A0anchor and the mobile access gateway. =A0Furthermo= re, making QoS
=A0=A0=A0parameters available on the MAG enables mapping these parameters t= o
=A0=A0=A0QoS rules being specific to the access technology which opera= tes
=A0=A0=A0below the mobile access gateway. =A0After such mapping, QoS= rules can
=A0=A0=A0be enforced on the access technology components, suc= h as an IEEE
=A0=A0=A0802.11e Wireless LAN controller.
=A0
=A0
_______________________________________________netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext

_______________________________________________<= br> netext mailing list
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext

=

--485b397dd071791bcb04bea73985-- From aland@deployingradius.com Fri Apr 27 02:26:32 2012 Return-Path: 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 A8CA921F86B4 for ; Fri, 27 Apr 2012 02:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, 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 536WTzioCfvh for ; Fri, 27 Apr 2012 02:26:32 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1A71621F8604 for ; Fri, 27 Apr 2012 02:26:32 -0700 (PDT) Message-ID: <4F9A662A.3020006@deployingradius.com> Date: Fri, 27 Apr 2012 11:26:02 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Apr 2012 04:28:47 -0700 Cc: netext@ietf.org, emu-chairs@tools.ietf.org Subject: Re: [netext] Question about standardizing new EAP attributes for use with Proxy MIP6 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:26:32 -0000 Basavaraj.Patil@nokia.com wrote: > These EAP attributes would be included by an MN when it performs EAP > authentication (EAP-SIM/AKA/AKA'). > > We would like your feedback and comments about this I-D. We would also > like to keep the EMU WG informed about this work since the expertise w.r.t > EAP attributes and methods lies there. I suggest posting a message to the EMU list. Include a link to the document, and ask for WG review. Joe pointed out that EAP-AKA is informational. I'm not sure it's OK to have this document (Proposed Standard) have a dependency on an Informational RFC. The dependency is marked "Informative" in the draft. But I don't see how a Proposed Standard document can have *no* Normative dependencies. It builds on pre-existing work, and must have some Normative dependencies. The document mentions EAP-AKA', but doesn't include a reference to RFC 5448. The IANA considerations section doesn't specify *where* the assignments come from. IANA is usually very literal, and needs detailed instructions. You should reference the "EAP-AKA and EAP-SIM Parameters" registry, and the "Attribute Types (Non-Skippable Attributes 0-127)" Alan DeKok. From Basavaraj.Patil@nokia.com Fri Apr 27 04:31:20 2012 Return-Path: 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 6ECFB21F861F for ; Fri, 27 Apr 2012 04:31:20 -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=[AWL=0.000, 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 OhKjm0V4E5MB for ; Fri, 27 Apr 2012 04:31:20 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 98B2821F8618 for ; Fri, 27 Apr 2012 04:31:19 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3RBVDdm015650; Fri, 27 Apr 2012 14:31:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 14:31:12 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Fri, 27 Apr 2012 13:31:12 +0200 From: To: Thread-Topic: Question about standardizing new EAP attributes for use with Proxy MIP6 Thread-Index: AQHNI99vfpEwHj03qkG7aNOq+SreKZauRkAA///PJQA= Date: Fri, 27 Apr 2012 11:31:11 +0000 Message-ID: In-Reply-To: <4F9A662A.3020006@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [96.226.49.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Apr 2012 11:31:12.0798 (UTC) FILETIME=[400703E0:01CD2469] X-Nokia-AV: Clean Cc: netext@ietf.org, emu-chairs@tools.ietf.org Subject: Re: [netext] Question about standardizing new EAP attributes for use with Proxy MIP6 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:31:20 -0000 Thanks Alan for the feedback. We can change the I-D state from PS to Informational as you and others have also suggested. We will send a pointer to the I-D to the EMU list. -Raj On 4/27/12 4:26 AM, "ext Alan DeKok" wrote: >Basavaraj.Patil@nokia.com wrote: >> These EAP attributes would be included by an MN when it performs EAP >> authentication (EAP-SIM/AKA/AKA'). >>=20 >> We would like your feedback and comments about this I-D. We would also >> like to keep the EMU WG informed about this work since the expertise >>w.r.t >> EAP attributes and methods lies there. > > I suggest posting a message to the EMU list. Include a link to the >document, and ask for WG review. > > Joe pointed out that EAP-AKA is informational. I'm not sure it's OK >to have this document (Proposed Standard) have a dependency on an >Informational RFC. > > The dependency is marked "Informative" in the draft. But I don't see >how a Proposed Standard document can have *no* Normative dependencies. >It builds on pre-existing work, and must have some Normative dependencies. > > The document mentions EAP-AKA', but doesn't include a reference to RFC >5448. > > The IANA considerations section doesn't specify *where* the >assignments come from. IANA is usually very literal, and needs detailed >instructions. You should reference the "EAP-AKA and EAP-SIM Parameters" >registry, and the "Attribute Types (Non-Skippable Attributes 0-127)" > > Alan DeKok. From pierrick.seite@orange.com Fri Apr 27 05:17:47 2012 Return-Path: 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 5E4A421F87A9 for ; Fri, 27 Apr 2012 05:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJGCKe9Gj9rK for ; Fri, 27 Apr 2012 05:17:45 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6762221F879F for ; Fri, 27 Apr 2012 05:17:44 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E0505D8A53; Fri, 27 Apr 2012 14:17:42 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0DF175D8A49; Fri, 27 Apr 2012 14:17:42 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 14:17:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD246F.BE13DBF4" Date: Fri, 27 Apr 2012 14:17:40 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202520F26@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt Thread-Index: Ac0kZyklMBo8QwlLRCSEltVFNp15oQABYUpw References: From: To: , X-OriginalArrivalTime: 27 Apr 2012 12:17:41.0877 (UTC) FILETIME=[BE72B250:01CD246F] Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 12:17:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD246F.BE13DBF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hui, =20 Thanks for the feedback.=20 =20 Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS = option. You're right, this is 3GPP QoS policy parameters but they can be = provisioned to the wifi network in a 3GPP/wi-fi interworking context. = And using the PMIP QoS option if we assume that the wi-fi access has no = PCC. In this situation, the mobile network (here LMA) provides the QoS = policies, in a 3GPP format, to the wi-fi access network (here the MAG) = which is supposed to do the mapping to DSCP policies that a wifi network = used to manage. =20 Hope that clarifies. =20 BR, Pierrick =20 De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Hui Deng Envoy=E9 : vendredi 27 avril 2012 13:16 =C0 : netext@ietf.org Objet : [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt =20 Hello authors,=20 =20 I have read through document, want to clarify below: =20 In the section 6, many parameters related to 3GPP air-interface has been = spcified like ARP, GDBR, GUBR, because wifi today doesn't have such capability, just wan to know = whether you would like to extend WLC capability to support and make wifi a much better wireless technology:) =20 If PMIP6 historically doesn't QoS, is that PCC will not be able to use = for PMIP6 based S5/S8 interfaces? =20 thanks for writing this document. =20 Best, =20 -Hui 2012/4/26 Sri Gundavelli Folks: Please comment on this draft. Lot of efforts went in to this from all = the Authors, please review and comment. http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt Regards Sri=20 On 3/13/12 8:40 AM, "Marco Liebsch" wrote: Please find an update of our draft about a QoS option for PMIP6 on the = IETF repository, which addresses comments from last meeting. The current version includes more = details about the proposed operation and QoS attributes.=20 =20 Marco =20 Filename: draft-liebsch-netext-pmip6-qos Revision: 01 Title: Quality of Service Option for Proxy Mobile = IPv6 Creation date: 2012-03-12 WG ID: Individual Submission Number of pages: 32 Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt =20 Abstract: This specification defines a new mobility option that can be used by the mobility entities in the Proxy Mobile IPv6 domain to exchange Quality of Service parameters associated with a subscriber's IP flows. Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values. This enables QoS policing and labeling of = packets to enforce QoS differentiation on the path between the local = mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules being specific to the access technology which operates below the mobile access gateway. After such mapping, QoS rules can be enforced on the access technology components, such as an IEEE 802.11e Wireless LAN controller. =20 =20 =09 ________________________________ _______________________________________________ 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 =20 ------_=_NextPart_001_01CD246F.BE13DBF4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Hui,

 

Thanks for the feedback.

 

Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS = option. You’re right, this is 3GPP QoS policy parameters but they = can be provisioned to the wifi network in a 3GPP/wi-fi interworking = context. And using the PMIP QoS option if we assume that the wi-fi = access has no PCC. In this situation, the mobile network (here LMA) = provides the QoS policies, in a 3GPP format, to the wi-fi access network = (here the MAG) which is supposed to do the mapping to DSCP policies that = a wifi network used to manage.

 

Hope that clarifies.

 

BR,

Pierrick

 

De : = netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Hui Deng
Envoy=E9 : vendredi 27 avril 2012 = 13:16
=C0 : netext@ietf.org
Objet : = [netext] Comments on = draft-liebsch-netext-pmip6-qos-01.txt

 

Hello = authors,

 

I = have read through document, want to clarify = below:

 

In the section 6, many parameters related to 3GPP = air-interface has been spcified like ARP, GDBR, = GUBR,

because wifi today = doesn't have such capability, just wan to know whether you would like to = extend WLC capability

to = support and make wifi a much better wireless = technology:)

 

If PMIP6 historically doesn't QoS, is that PCC will = not be able to use for PMIP6 based S5/S8 = interfaces?

 

thanks for writing = this document.

 

Best,

 

-Hui

2012/4/26 Sri Gundavelli <sgundave@cisco.com>

Folks:
<= br>Please comment on this draft. Lot of efforts went in to this from all = the Authors, please review and comment.

http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.txt



Regards
Sri




On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> = wrote:

Please = find an update of our draft about a QoS option for PMIP6 on the IETF = repository, which
addresses comments from last meeting. The current = version includes more details about the
proposed operation and QoS = attributes.
 
Marco
 
Filename: =            draft-l= iebsch-netext-pmip6-qos
Revision: =             &= nbsp;01
Title: =             &= nbsp;        Quality of Service = Option for Proxy Mobile IPv6
Creation date: =   2012-03-12
WG ID: =             &= nbsp;    Individual Submission
Number of pages: = 32
Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.txt
 
Abstract:
   This specification = defines a new mobility option that can be used = by
   the mobility entities in the Proxy Mobile IPv6 = domain to exchange
   Quality of Service parameters = associated with a subscriber&#39;s IP
   flows. =  Using the QoS option, the local mobility anchor and = the
   mobile access gateway can exchange available = QoS attributes and
   associated values.  This = enables QoS policing and labeling of packets
   to = enforce QoS differentiation on the path between the local = mobility
   anchor and the mobile access gateway. =  Furthermore, making QoS
   parameters available = on the MAG enables mapping these parameters to
   QoS = rules being specific to the access technology which = operates
   below the mobile access gateway. =  After such mapping, QoS rules can
   be enforced = on the access technology components, such as an = IEEE
   802.11e Wireless LAN = controller.
 
 

_________________________= ______________________
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

 

------_=_NextPart_001_01CD246F.BE13DBF4-- From denghui02@gmail.com Fri Apr 27 06:37:08 2012 Return-Path: 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 6CBE021F865B for ; Fri, 27 Apr 2012 06:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.396 X-Spam-Level: X-Spam-Status: No, score=-103.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 rK3Z4vMrvMov for ; Fri, 27 Apr 2012 06:37:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7081021F865F for ; Fri, 27 Apr 2012 06:37:07 -0700 (PDT) Received: by yenm5 with SMTP id m5so411486yen.31 for ; Fri, 27 Apr 2012 06:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gv9IktYMSM7lUn6uvtZNO17ygiknjhiawwntE4rimKE=; b=VwR54ofUlD+x+j5bHraphL6TP3IyG9ZcFVWoB9dMdOuXvALHaT2is8NQalit1NYLEd FbsmHJMZbwJYx79dl6+pcPpQC6byAF1B3zNAqqmyhnSNI0LC/DtXj/AOLTfcPHCSiEJt zjWdm8y7lNq/TQclYYchGaQR5F0ptnYanv6p0k+7sFJnOjpgs/p0DVlTX/v2cHqzblpC 6h4B0CJ9OsQuANp1I8OITxrUY1RqbZKKbEOC4q6yDwWe75emjdVeO4YCi9Rj6nZ5PRS6 yquu3MdHhQIitr7u4GnJLKbvWQv4NjfRh8HjBS0psvdDhSrt8dc8BmxU4V99nKAXNRlL +kcg== MIME-Version: 1.0 Received: by 10.236.145.34 with SMTP id o22mr11591453yhj.7.1335533826905; Fri, 27 Apr 2012 06:37:06 -0700 (PDT) Received: by 10.147.115.6 with HTTP; Fri, 27 Apr 2012 06:37:06 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202520F26@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C46202520F26@ftrdmel0.rd.francetelecom.fr> Date: Fri, 27 Apr 2012 21:37:06 +0800 Message-ID: From: Hui Deng To: pierrick.seite@orange.com Content-Type: multipart/alternative; boundary=20cf303b3cdf5695ee04bea933cf Cc: netext@ietf.org Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 13:37:08 -0000 --20cf303b3cdf5695ee04bea933cf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pierrick, thanks for your quick response, but you also deliver dscp as well? -Hui 2012/4/27 > Hi Hui,**** > > ** ** > > Thanks for the feedback. **** > > ** ** > > Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS > option. You=92re right, this is 3GPP QoS policy parameters but they can b= e > provisioned to the wifi network in a 3GPP/wi-fi interworking context. And > using the PMIP QoS option if we assume that the wi-fi access has no PCC. = In > this situation, the mobile network (here LMA) provides the QoS policies, = in > a 3GPP format, to the wi-fi access network (here the MAG) which is suppos= ed > to do the mapping to DSCP policies that a wifi network used to manage.***= * > > ** ** > > Hope that clarifies.**** > > ** ** > > BR,**** > > Pierrick**** > > ** ** > > *De :* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *De la > part de* Hui Deng > *Envoy=E9 :* vendredi 27 avril 2012 13:16 > *=C0 :* netext@ietf.org > *Objet :* [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt**** > > ** ** > > Hello authors, **** > > **** > > I have read through document, want to clarify below:**** > > **** > > In the section 6, many parameters related to 3GPP air-interface has been > spcified like ARP, GDBR, GUBR,**** > > because wifi today doesn't have such capability, just wan to know whether > you would like to extend WLC capability**** > > to support and make wifi a much better wireless technology:)**** > > **** > > If PMIP6 historically doesn't QoS, is that PCC will not be able to use fo= r > PMIP6 based S5/S8 interfaces?**** > > **** > > thanks for writing this document.**** > > **** > > Best,**** > > **** > > -Hui**** > > 2012/4/26 Sri Gundavelli **** > > Folks: > > Please comment on this draft. Lot of efforts went in to this from all the > Authors, please review and comment. > > http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > > > Regards > Sri **** > > > > > > On 3/13/12 8:40 AM, "Marco Liebsch" wrote:**** > > Please find an update of our draft about a QoS option for PMIP6 on the > IETF repository, which > addresses comments from last meeting. The current version includes more > details about the > proposed operation and QoS attributes. > > Marco > > Filename: draft-liebsch-netext-pmip6-qos > Revision: 01 > Title: Quality of Service Option for Proxy Mobile IP= v6 > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 32 > Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > Abstract: > This specification defines a new mobility option that can be used by > the mobility entities in the Proxy Mobile IPv6 domain to exchange > Quality of Service parameters associated with a subscriber's IP > flows. Using the QoS option, the local mobility anchor and the > mobile access gateway can exchange available QoS attributes and > associated values. This enables QoS policing and labeling of packets > to enforce QoS differentiation on the path between the local mobility > anchor and the mobile access gateway. Furthermore, making QoS > parameters available on the MAG enables mapping these parameters to > QoS rules being specific to the access technology which operates > below the mobile access gateway. After such mapping, QoS rules can > be enforced on the access technology components, such as an IEEE > 802.11e Wireless LAN controller. > > **** > ------------------------------ > > _______________________________________________ > 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**** > > ** ** > --20cf303b3cdf5695ee04bea933cf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Pierrick,
=A0
thanks for your quick response,
=A0
but you also deliver dscp as well?
=A0
-Hui

2012/4/27 <pierrick.seite@orange.com>

Hi Hui,

=A0

Thanks for the f= eedback.

=A0

Actually, parame= ters like , ARP, GDBR, GUBR are optional in the QoS option. You=92re right,= this is 3GPP QoS policy parameters but they can be provisioned to the wifi= network in a 3GPP/wi-fi interworking context. And using the PMIP QoS optio= n if we assume that the wi-fi access has no PCC. In this situation, the mob= ile network (here LMA) provides the QoS policies, in a 3GPP format, to the = wi-fi access network (here the MAG) which is supposed to do the mapping to = DSCP policies that a wifi network used to manage.

=A0

Hope that clarif= ies.

=A0

BR,

Pierrick<= u>

=A0

De=A0: netext-bounces@ietf.org [mail= to:netext-boun= ces@ietf.org] De la part de Hui Deng
Envoy=E9=A0: vendredi 27 avril 2012 13:16
=C0=A0: netext@ietf.org
Obj= et=A0: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt

=A0

Hello authors,

=A0

I have read through document, want to clarify below:=

=A0

In the section 6, many parameters related to 3GPP ai= r-interface has been spcified like ARP, GDBR, GUBR,

because wifi today doesn't have such capability,= just wan to know whether you would like to extend WLC capability=

to support and make wifi a much better wireless tech= nology:)

=A0

If PMIP6 historically doesn't QoS, is that PCC w= ill not be able to use for PMIP6 based S5/S8 interfaces?

<= /div>

=A0

thanks for writing this=A0document.

=A0

Best,

=A0

-Hui

<= /div>

2012/4/26 Sri Gundavelli <sgundave@cisco.com>

Folks:

Please comment on this draft. L= ot of efforts went in to this from all the Authors, please review and comme= nt.

http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.txt



Regards
Sri=





= On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:<= u>

Please find an u= pdate of our draft about a QoS option for PMIP6 on the IETF repository, whi= ch
addresses comments from last meeting. The current version includes more det= ails about the
proposed operation and QoS attributes.
=A0
Marco=A0
Filename: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0draft-liebsch-netext-pm= ip6-qos
Revision: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A001
Title: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Quali= ty of Service Option for Proxy Mobile IPv6
Creation date: =A0=A02012-03-= 12
WG ID: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Individual = Submission
Number of pages: 32
Link: http://www.ietf.= org/id/draft-liebsch-netext-pmip6-qos-01.txt
=A0
Abstract:
=A0=A0=A0This specification defines a new mobility opti= on that can be used by
=A0=A0=A0the mobility entities in the Proxy Mobil= e IPv6 domain to exchange
=A0=A0=A0Quality of Service parameters associa= ted with a subscriber&#39;s IP
=A0=A0=A0flows. =A0Using the QoS option, the local mobility anchor and the<= br>=A0=A0=A0mobile access gateway can exchange available QoS attributes and=
=A0=A0=A0associated values. =A0This enables QoS policing and labeling o= f packets
=A0=A0=A0to enforce QoS differentiation on the path between th= e local mobility
=A0=A0=A0anchor and the mobile access gateway. =A0Furthermore, making QoS=A0=A0=A0parameters available on the MAG enables mapping these parameters= to
=A0=A0=A0QoS rules being specific to the access technology which ope= rates
=A0=A0=A0below the mobile access gateway. =A0After such mapping, Q= oS rules can
=A0=A0=A0be enforced on the access technology components, such as an IEEE=A0=A0=A0802.11e Wireless LAN controller.
=A0
=A0

= _______________________________________________
netext mailing list
<= a href=3D"http://netext@ietf.org" target=3D"_blank">netext@ietf.org
= = https://www.ietf.org/mailman/listinfo/netext


___________________= ____________________________
netext mailing list
netext@ietf.org
https://www.ietf.or= g/mailman/listinfo/netext

=A0

<= /div>

--20cf303b3cdf5695ee04bea933cf-- From pierrick.seite@orange.com Fri Apr 27 08:17:37 2012 Return-Path: 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 EDDDD21F86EC for ; Fri, 27 Apr 2012 08:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2qw1INSkoQh for ; Fri, 27 Apr 2012 08:17:35 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2A21F86D1 for ; Fri, 27 Apr 2012 08:17:34 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 365D65D885A; Fri, 27 Apr 2012 17:17:31 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 23DD45D84F0; Fri, 27 Apr 2012 17:17:31 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 17:17:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2488.DCE44CC5" Date: Fri, 27 Apr 2012 17:17:29 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202520FB4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt Thread-Index: Ac0keuoYK740FUpoR6qcVdp2992BLAADJNBA References: <843DA8228A1BA74CA31FB4E111A5C46202520F26@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 27 Apr 2012 15:17:30.0903 (UTC) FILETIME=[DD356A70:01CD2488] Cc: netext@ietf.org Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:17:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2488.DCE44CC5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hui, =20 Please see inline =20 Pierrick =20 De : Hui Deng [mailto:denghui02@gmail.com]=20 Envoy=E9 : vendredi 27 avril 2012 15:37 =C0 : SEITE Pierrick RD-RESA-REN Cc : netext@ietf.org Objet : Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt =20 Pierrick,=20 =20 thanks for your quick response, =20 but you also deliver dscp as well? =20 Yes, the QoS option shall at least include a dscp. If QoS policy is a = 3GPP policy, the LMA relies on default QCI/DSCP mapping as explained in = section 3.4. Optional qos parameters may be used by the wi-fi access = network to do its own mapping, but this is out of scope of the current = document. The other reason to include a DSCP is that the QoS option may = be used in another context that 3GPP/Wi-Fi, we have to document this = use-case.=20 =20 =20 -Hui 2012/4/27 Hi Hui, =20 Thanks for the feedback.=20 =20 Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS = option. You're right, this is 3GPP QoS policy parameters but they can be = provisioned to the wifi network in a 3GPP/wi-fi interworking context. = And using the PMIP QoS option if we assume that the wi-fi access has no = PCC. In this situation, the mobile network (here LMA) provides the QoS = policies, in a 3GPP format, to the wi-fi access network (here the MAG) = which is supposed to do the mapping to DSCP policies that a wifi network = used to manage. =20 Hope that clarifies. =20 BR, Pierrick =20 De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Hui Deng Envoy=E9 : vendredi 27 avril 2012 13:16 =C0 : netext@ietf.org Objet : [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt =20 Hello authors,=20 =20 I have read through document, want to clarify below: =20 In the section 6, many parameters related to 3GPP air-interface has been = spcified like ARP, GDBR, GUBR, because wifi today doesn't have such capability, just wan to know = whether you would like to extend WLC capability to support and make wifi a much better wireless technology:) =20 If PMIP6 historically doesn't QoS, is that PCC will not be able to use = for PMIP6 based S5/S8 interfaces? =20 thanks for writing this document. =20 Best, =20 -Hui 2012/4/26 Sri Gundavelli Folks: Please comment on this draft. Lot of efforts went in to this from all = the Authors, please review and comment. http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt Regards Sri=20 On 3/13/12 8:40 AM, "Marco Liebsch" wrote: Please find an update of our draft about a QoS option for PMIP6 on the = IETF repository, which addresses comments from last meeting. The current version includes more = details about the proposed operation and QoS attributes.=20 =20 Marco =20 Filename: draft-liebsch-netext-pmip6-qos Revision: 01 Title: Quality of Service Option for Proxy Mobile = IPv6 Creation date: 2012-03-12 WG ID: Individual Submission Number of pages: 32 Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt =20 Abstract: This specification defines a new mobility option that can be used by the mobility entities in the Proxy Mobile IPv6 domain to exchange Quality of Service parameters associated with a subscriber's IP flows. Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values. This enables QoS policing and labeling of = packets to enforce QoS differentiation on the path between the local = mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules being specific to the access technology which operates below the mobile access gateway. After such mapping, QoS rules can be enforced on the access technology components, such as an IEEE 802.11e Wireless LAN controller. =20 =20 =09 ________________________________ _______________________________________________ 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 =20 =20 ------_=_NextPart_001_01CD2488.DCE44CC5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Hui,

 

Please see inline

 

Pierrick

 

De : Hui Deng = [mailto:denghui02@gmail.com]
Envoy=E9 : vendredi 27 = avril 2012 15:37
=C0 : SEITE Pierrick = RD-RESA-REN
Cc : netext@ietf.org
Objet : = Re: [netext] Comments on = draft-liebsch-netext-pmip6-qos-01.txt

 

Pierrick,

 

thanks for your quick = response,

 

but you also deliver dscp as well?

 

Yes, the QoS option shall at least include a dscp. If QoS policy is a = 3GPP policy, the LMA relies on default QCI/DSCP mapping as explained in = section 3.4. Optional qos parameters may be used by the wi-fi access = network to do its own mapping, but this is out of scope of the current = document. The other reason to include a DSCP is that the QoS option may = be used in another context that 3GPP/Wi-Fi, we have to document this = use-case.

 

 

-Hui

2012/4/27 <pierrick.seite@orange.com>

Hi Hui,

 

Thanks for the feedback.

 

Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS = option. You’re right, this is 3GPP QoS policy parameters but they = can be provisioned to the wifi network in a 3GPP/wi-fi interworking = context. And using the PMIP QoS option if we assume that the wi-fi = access has no PCC. In this situation, the mobile network (here LMA) = provides the QoS policies, in a 3GPP format, to the wi-fi access network = (here the MAG) which is supposed to do the mapping to DSCP policies that = a wifi network used to manage.

 

Hope that clarifies.

 

BR,

Pierrick

 

De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de Hui = Deng
Envoy=E9 : vendredi 27 avril 2012 = 13:16
=C0 : netext@ietf.org
Objet : [netext] = Comments on = draft-liebsch-netext-pmip6-qos-01.txt

 <= /o:p>

Hello = authors,

 <= /o:p>

I have read = through document, want to clarify below:

 <= /o:p>

In the = section 6, many parameters related to 3GPP air-interface has been = spcified like ARP, GDBR, GUBR,

because = wifi today doesn't have such capability, just wan to know whether you = would like to extend WLC capability

to support = and make wifi a much better wireless = technology:)

 <= /o:p>

If PMIP6 = historically doesn't QoS, is that PCC will not be able to use for PMIP6 = based S5/S8 interfaces?

 <= /o:p>

thanks for = writing this document.

 <= /o:p>

Best,

 <= /o:p>

-Hui

2012/4/26 = Sri Gundavelli <sgundave@cisco.com>

Folks:
<= br>Please comment on this draft. Lot of efforts went in to this from all = the Authors, please review and comment.

http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.txt



Regards
Sri =




On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> = wrote:

Please = find an update of our draft about a QoS option for PMIP6 on the IETF = repository, which
addresses comments from last meeting. The current = version includes more details about the
proposed operation and QoS = attributes.
 
Marco
 
Filename: =            draft-l= iebsch-netext-pmip6-qos
Revision: =             &= nbsp;01
Title: =             &= nbsp;        Quality of Service = Option for Proxy Mobile IPv6
Creation date: =   2012-03-12
WG ID: =             &= nbsp;    Individual Submission
Number of pages: = 32
Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.txt
 
Abstract:
   This specification = defines a new mobility option that can be used = by
   the mobility entities in the Proxy Mobile IPv6 = domain to exchange
   Quality of Service parameters = associated with a subscriber&#39;s IP
   flows. =  Using the QoS option, the local mobility anchor and = the
   mobile access gateway can exchange available = QoS attributes and
   associated values.  This = enables QoS policing and labeling of packets
   to = enforce QoS differentiation on the path between the local = mobility
   anchor and the mobile access gateway. =  Furthermore, making QoS
   parameters available = on the MAG enables mapping these parameters to
   QoS = rules being specific to the access technology which = operates
   below the mobile access gateway. =  After such mapping, QoS rules can
   be enforced = on the access technology components, such as an = IEEE
   802.11e Wireless LAN = controller.
 
 

_________________________= ______________________
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

 <= /o:p>

 

------_=_NextPart_001_01CD2488.DCE44CC5-- From sarikaya2012@gmail.com Fri Apr 27 08:21:12 2012 Return-Path: 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 8D18A21F863D for ; Fri, 27 Apr 2012 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 sxHysHGVWcGb for ; Fri, 27 Apr 2012 08:21:11 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 804F921F8639 for ; Fri, 27 Apr 2012 08:21:11 -0700 (PDT) Received: by ghbg16 with SMTP id g16so532034ghb.31 for ; Fri, 27 Apr 2012 08:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Cb+BgwWDHhyxkKphUA7HePTms2mN9Yytb8OXoQ8YXnY=; b=WJSxiGzJ6HjsGGJS41jzTq+PKGx7JXGJvcHPoqUEWx0DC/6noE05s9JVjPyg5zOTtH DvVuH6QhqRjuQTwqbwti9m8u4QLQ8b2fGm9UarKYBmy8miGi4AhdjjyJR1OmsgKJpNxE 21mS+ogf1jF+0oeJaV1CVAME+TBRUjPiGH89+aY08grwaFsIzHk9kf2UINoDOMCb0ZMN 8MHLtB0GqetsPbU1/0hJ8OY2p2CgsUA/nHUnsMtoAACxi7PocDl3YdAQ6JUOmRLZFpmA ve3JGZF5W5A5RQmEucEswB12ZQC3mh1xg023sgKPf7BU+DnykObaQqoAqgicw1PrjzHz KLBQ== MIME-Version: 1.0 Received: by 10.50.185.193 with SMTP id fe1mr3103303igc.9.1335540070811; Fri, 27 Apr 2012 08:21:10 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Fri, 27 Apr 2012 08:21:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Apr 2012 10:21:10 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org Subject: Re: [netext] Question about EAP method applicability.. X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 27 Apr 2012 15:21:12 -0000 Hi Basavaraj, Thanks for this mail. I believe this is the real point with this draft and it should have been checked before WG adoption call, right? Pls see inline. On Thu, Apr 26, 2012 at 10:54 AM, wrote: > > Hello, > > The I-D mentions EAP methods EAP-AKA/AKA'. Subsequent emails have also > mentioned EAP-SIM. > The above set of EAP methods are generally applicable in a 3GPP operator > environment. Absolutely! If you read the description of these attributes, the attribute naming follows EAP-AKA/AKA'. So these are defined in addition to what we have in RFC 5187 and 5448 which are defined to be used by 3GPP. Take AT_VIRTUAL_NETWORK_ID, why virtual, I could not understand, it says the virtual network is implemented based on the 3GPP APN primitive. >From PMIPv6 point of view, PMIPv6 MN does not carry apn, i.e. LMA address, the system assigns it for this MN. Similar arguments can be said for the others, i.e. they are all for 3GPP. > > Question: Are these attributes also valid for example if the EAP method > used is EAP-TLS or EAP-TTLS? > > It would make the applicability of these attributes wider if that is the > case. EAP-TLS encapsulates TLS into EAP messages (EAP Request and EAP Response). So if anything is to be applicable to EAP-TLS, it should first be added to TLS, i.e. then you have to go to TLS WG. Thanks again for this message. I am hoping that this draft is going to be the last attempt to modify PMIPv6 MN :). Regards, Behcet From sarikaya2012@gmail.com Fri Apr 27 08:34:18 2012 Return-Path: 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 136AB21F87F1 for ; Fri, 27 Apr 2012 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7So7P8+Jw6gO for ; Fri, 27 Apr 2012 08:34:17 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4BB21F880B for ; Fri, 27 Apr 2012 08:34:17 -0700 (PDT) Received: by yhkk25 with SMTP id k25so547904yhk.31 for ; Fri, 27 Apr 2012 08:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BpHpyLVsXT2CQHzpdwrTvKaDDznGbPvGc6jtypOPWXo=; b=NpfIpoqxawYrR1w1aVKEjyutXEgpcNKY6QTSeUYEnw1abta3dxijEJ+Emoie6nAFFT +P/6xCz/NTMAo1DVUxEAeIde8wV8iFsJk6yfJjlJRpBG/5yzj/3Z0LeoxmuG+pwt6IdY WonycNQCwq5fLZnU8hknSzh3caZzZgQ5hKoe8LMm+TbIb/R/3QohEfE3xdK+g8bJrsoH L7/XAblAC46IuPOVGc8UE5IXIkAskDHE2kOTjlBDctClYKF3kOeO89ufwXgozJtUJTMk l35rXMciSzm5yNfviyelQca6r+upOivhXowmI8LenqidYbNp6zg2xSsIHjKuO1rfB0qQ EU3Q== MIME-Version: 1.0 Received: by 10.50.178.106 with SMTP id cx10mr2832709igc.9.1335540856616; Fri, 27 Apr 2012 08:34:16 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Fri, 27 Apr 2012 08:34:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Apr 2012 10:34:16 -0500 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 27 Apr 2012 15:34:18 -0000 Hi Basavaraj, Pls see inline. On Thu, Apr 26, 2012 at 10:44 AM, wrote: > > Inline: > > On 4/26/12 9:59 AM, "ext Behcet Sarikaya" wrote: > >>Hi Basavaraj, >> >>>>2. As I said above, the draft's main concern is MN authentication on >>>>Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links >>>>and Wi-Fi link is a shared link. >>>>Does this raise any concerns to you? >>> >>> No. >> >>Really? >> >>Imagine MAG as defined in RFC 5213 (which assumes that each MN is on a >>point-to-point link) is connected to a shared link. > > We all understand the link model requirements for PMIP6. Nothing is being > changed there. > >>I think the result will be disastrous. > > Why? Can you elaborate? > >> If there is only one MN, it may >>be OK but as more MNs join, especially in hot spots then the problems >>start. > > Why? Are you saying that the current link model for PMIP6 allows only a > single MN to attach to a WiFi AP (as an example)? > What is the basis for saying that having many MNs attach to a MAG in a > hotspot (assuming wifi) will result in problems? > Is there any work that you have done to make such a statement? As you know similar concerns have been voiced over and over again in Netext. Isn't it time to do something on this? Clarify that everything will work fine or if not, then propose solutions. If you look at SaMOG work in 3GPP, they repeatedly said WiFi should provide point to point link to UEs. Why do you think they said so if they anticipated no problems? Behcet From sgundave@cisco.com Fri Apr 27 09:15:06 2012 Return-Path: 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 B5AA221F8600 for ; Fri, 27 Apr 2012 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 O9ZPmUufWagv for ; Fri, 27 Apr 2012 09:15:06 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1614B21F85FD for ; Fri, 27 Apr 2012 09:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3924; q=dns/txt; s=iport; t=1335543306; x=1336752906; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uSj4oj8IFGmIj0hIZW5jMyUorp+e5v3Vu286sou8b2A=; b=HnUb2c25oqHYZOEbg/7TacoJJIqnL7p5+HJcUK0Ar8l92P/fTyHeoKph IMuJ+0Y7hM4+8nFUOnLPeuqbBgzE1SfJvThIDinWdMlg51qZekYo6iZOv DBHyisxSjzJbwzXMxLKoGmy+KkYU++f4852gvlw5S2GQGbBASIFYZhBYl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALXFmk+rRDoH/2dsb2JhbABEsW+BB4IJAQEBAwEBAQEPASc0CwULCxIGLiEGIg4ZGweHXQMGBAycIZZLDYlPBIoHhlljBIhjjRqLPYMagWmDCA X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="42402573" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 27 Apr 2012 16:15:05 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3RGF5rs013022; Fri, 27 Apr 2012 16:15:05 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Sri Gundavelli In-Reply-To: Date: Fri, 27 Apr 2012 09:15:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:15:06 -0000 Hi Behcet: Sorry to jump in to this thread. I'm going to respond/clarify only on = one specific comment (may be tangential to your discussion), as I'm not = following this thread/rest of the discussion. I want to clarify only = that one part though about WLAN, PMIPv6 and SaMOG. >> Why? Are you saying that the current link model for PMIP6 allows only = a >> single MN to attach to a WiFi AP (as an example)? >> What is the basis for saying that having many MNs attach to a MAG in = a >> hotspot (assuming wifi) will result in problems? >> Is there any work that you have done to make such a statement? >=20 >=20 > As you know similar concerns have been voiced over and over again in = Netext. >=20 > Isn't it time to do something on this? >=20 > Clarify that everything will work fine It is true, WLAN access is a shared media and what we need in Proxy = Mobile IPv6 is essentially the ability for the MAG to advertise unicast = RA's/or in general keep multicast traffic map to a single receiver (as = clarified in RFC-6085). This is today the case on WLAN access networks. = A client when it sends a multicast/broadcast packet, that packet is not = sensed by the other receivers directly on the air interface, as in the = case of ethernet, but rather it hits the access point and its the = function if the access point to stream it down with using the correct = multicast keys; this in essence is giving the model that we needed, as = long as the access point/WLC blocks multicast traffic from wireless = clients from other wireless clients. All most every WLAN deployment is = typically configured to operate it this way. The SaMOG architecture (or = the WLAN IWK document that I've published), makes that assumption with = impact to link model, else SaMOG architecture (with either of S2a = protocol interfaces) is broken and un deployable. Regards Sri On Apr 27, 2012, at 8:34 AM, Behcet Sarikaya wrote: > Hi Basavaraj, >=20 > Pls see inline. >=20 > On Thu, Apr 26, 2012 at 10:44 AM, wrote: >>=20 >> Inline: >>=20 >> On 4/26/12 9:59 AM, "ext Behcet Sarikaya" = wrote: >>=20 >>> Hi Basavaraj, >>>=20 >>>>> 2. As I said above, the draft's main concern is MN authentication = on >>>>> Wi-Fi links. As we all know, PMIPv6 is based on point-to-point = links >>>>> and Wi-Fi link is a shared link. >>>>> Does this raise any concerns to you? >>>>=20 >>>> No. >>>=20 >>> Really? >>>=20 >>> Imagine MAG as defined in RFC 5213 (which assumes that each MN is on = a >>> point-to-point link) is connected to a shared link. >>=20 >> We all understand the link model requirements for PMIP6. Nothing is = being >> changed there. >>=20 >>> I think the result will be disastrous. >>=20 >> Why? Can you elaborate? >>=20 >>> If there is only one MN, it may >>> be OK but as more MNs join, especially in hot spots then the = problems >>> start. >>=20 >> Why? Are you saying that the current link model for PMIP6 allows only = a >> single MN to attach to a WiFi AP (as an example)? >> What is the basis for saying that having many MNs attach to a MAG in = a >> hotspot (assuming wifi) will result in problems? >> Is there any work that you have done to make such a statement? >=20 >=20 > As you know similar concerns have been voiced over and over again in = Netext. >=20 > Isn't it time to do something on this? >=20 > Clarify that everything will work fine >=20 > or >=20 > if not, then propose solutions. >=20 > If you look at SaMOG work in 3GPP, they repeatedly said WiFi should > provide point to point link to UEs. >=20 > Why do you think they said so if they anticipated no problems? >=20 > Behcet > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Fri Apr 27 09:29:37 2012 Return-Path: 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 55AE721F86F5 for ; Fri, 27 Apr 2012 09:29:37 -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 y4c0dfymKxgV for ; Fri, 27 Apr 2012 09:29:36 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A344021F86F3 for ; Fri, 27 Apr 2012 09:29:36 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3RGTM6F029516; Fri, 27 Apr 2012 19:29:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 19:29:31 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0283.004; Fri, 27 Apr 2012 18:29:31 +0200 From: To: Thread-Topic: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt Thread-Index: AQHNIvmxXoE5SUVh4EqssCBV4/H4f5argS0AgAGRogD//7jDAIAB41wA//+7m4A= Date: Fri, 27 Apr 2012 16:29:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [87.254.201.145] Content-Type: text/plain; charset="Windows-1252" Content-ID: <515680BAA7F17640B078B09F66882126@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Apr 2012 16:29:31.0251 (UTC) FILETIME=[EC563430:01CD2492] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:29:37 -0000 Behcet, On 4/27/12 10:34 AM, "ext Behcet Sarikaya" wrote: >Hi Basavaraj, > >Pls see inline. > >On Thu, Apr 26, 2012 at 10:44 AM, wrote: >> >> Inline: >> >> On 4/26/12 9:59 AM, "ext Behcet Sarikaya" >>wrote: >> >>>Hi Basavaraj, >>> >>>>>2. As I said above, the draft's main concern is MN authentication on >>>>>Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links >>>>>and Wi-Fi link is a shared link. >>>>>Does this raise any concerns to you? >>>> >>>> No. >>> >>>Really? >>> >>>Imagine MAG as defined in RFC 5213 (which assumes that each MN is on a >>>point-to-point link) is connected to a shared link. >> >> We all understand the link model requirements for PMIP6. Nothing is >>being >> changed there. >> >>>I think the result will be disastrous. >> >> Why? Can you elaborate? >> >>> If there is only one MN, it may >>>be OK but as more MNs join, especially in hot spots then the problems >>>start. >> >> Why? Are you saying that the current link model for PMIP6 allows only a >> single MN to attach to a WiFi AP (as an example)? >> What is the basis for saying that having many MNs attach to a MAG in a >> hotspot (assuming wifi) will result in problems? >> Is there any work that you have done to make such a statement? > > >As you know similar concerns have been voiced over and over again in >Netext. This is just FUD. Please explain or reference what these concerns are that have been voiced in Netext. If you can list these concerns clearly, I think everyone on this list would appreciate it. > >Isn't it time to do something on this? We can=8A If there are issues/concerns. So the ball is in your court to explain to the WG what these issues/concerns are. > >Clarify that everything will work fine What do you mean "everything will work fine"? Can you tell me what does not work today?=20 > >or > >if not, then propose solutions. > > If you look at SaMOG work in 3GPP, they repeatedly said WiFi should >provide point to point link to UEs. > >Why do you think they said so if they anticipated no problems? Please tell me why 3GPP said so. I have no idea what the details of the SaMOG work in 3GPP are. Maybe you can explain to the WG the reasoning of 3GPP and what those anticipated problems are. -Raj > >Behcet From sarikaya2012@gmail.com Fri Apr 27 09:43:41 2012 Return-Path: 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 74A4221F868A for ; Fri, 27 Apr 2012 09:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XDrhcu8G-Mgy for ; Fri, 27 Apr 2012 09:43:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9BD621F8711 for ; Fri, 27 Apr 2012 09:43:40 -0700 (PDT) Received: by iazz13 with SMTP id z13so1528019iaz.31 for ; Fri, 27 Apr 2012 09:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=uppR7vF4VZTpd8IgfZWKnOVOc2dVO/hdI97y3USUdt4=; b=Qu4VPoEjvQ8jvj9reKlGvEIpyz40BjY47N5qnslKKFb12IU9n4CARBi6+3Fpj1cyiI ZJZUiCugmXuNKbLcozpVNLRM/zrcP9rPontShDDeBbMejtzHYAS5l6NmjI/6RLsHey7l 59aMqyp77wwkV+PxOexlb7Jw8u7dCg4UtO9/c6nE/e8H+UxcR474pvg9CTIrTwn0E11H LBcV8VQzz8xPfp54Xpm3+tnsenUE9HoXKa+x54uolxkl66Q9Ppdh1EVwJKKJ/zomtSnG rlGEbU9jf3u7alItx23k25fZDZui2mU4tLc+yUt5UbzXJl6rn8eFlileZe2uiLfbrISM bJtg== MIME-Version: 1.0 Received: by 10.50.222.202 with SMTP id qo10mr3526039igc.0.1335545020205; Fri, 27 Apr 2012 09:43:40 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Fri, 27 Apr 2012 09:43:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Apr 2012 11:43:40 -0500 Message-ID: From: Behcet Sarikaya To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 27 Apr 2012 16:43:41 -0000 Hi Sri, Thanks for chipping in your valuable views on this. Basavaraj seems to disagree that there is a problem there but I don't know = why? On Fri, Apr 27, 2012 at 11:15 AM, Sri Gundavelli wrote= : > Hi Behcet: > > Sorry to jump in to this thread. I'm going to respond/clarify only on one= specific comment (may be tangential to your discussion), as I'm not follow= ing this thread/rest of the discussion. I want to clarify only that one par= t though about WLAN, PMIPv6 and SaMOG. > > > >>> Why? Are you saying that the current link model for PMIP6 allows only a >>> single MN to attach to a WiFi AP (as an example)? >>> What is the basis for saying that having many MNs attach to a MAG in a >>> hotspot (assuming wifi) will result in problems? >>> Is there any work that you have done to make such a statement? >> >> >> As you know similar concerns have been voiced over and over again in Net= ext. >> >> Isn't it time to do something on this? >> >> Clarify that everything will work fine > > > > It is true, WLAN access is a shared media and what we need in Proxy >Mobile IPv6 is essentially the ability for the MAG to advertise unicast >RA's/or in general keep multicast traffic map to a single receiver (as >clarified in RFC-6085). This is today the case on WLAN access >networks. A client when it sends a multicast/broadcast packet, that >packet is not sensed by the other receivers directly on the air interface, >as in the case of ethernet, but rather it hits the access point and its th= e >function if the access point to stream it down with using the correct >multicast keys; this in essence is giving the model that we needed, as l >ong as the access point/WLC blocks multicast traffic from wireless >clients from other wireless clients. =A0All most every WLAN deployment is >typically configured to operate it this way. The SaMOG architecture (or >the WLAN IWK document that I've published), makes that assumption >with impact to link model, else SaMOG architecture (with either of S2a >protocol interfaces) is broken and un deployable. > I wonder how do you map to a single receiver if there are more than one receivers, i.e. the correct receiver? You mentioned WLAN IWK document, can you provide the link? As you know there are also Layer 2 solutions. I think we need to document it in Netext, maybe the chairs can add a milestone on this to the charter? Regards, Behcet > > > Regards > Sri > > > > > > > On Apr 27, 2012, at 8:34 AM, Behcet Sarikaya wrote: > >> Hi Basavaraj, >> >> Pls see inline. >> >> On Thu, Apr 26, 2012 at 10:44 AM, =A0 wrote: >>> >>> Inline: >>> >>> On 4/26/12 9:59 AM, "ext Behcet Sarikaya" wrot= e: >>> >>>> Hi Basavaraj, >>>> >>>>>> 2. As I said above, the draft's main concern is MN authentication on >>>>>> Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links >>>>>> and Wi-Fi link is a shared link. >>>>>> Does this raise any concerns to you? >>>>> >>>>> No. >>>> >>>> Really? >>>> >>>> Imagine MAG as defined in RFC 5213 (which assumes that each MN is on a >>>> point-to-point link) is connected to a shared link. >>> >>> We all understand the link model requirements for PMIP6. Nothing is bei= ng >>> changed there. >>> >>>> I think the result will be disastrous. >>> >>> Why? Can you elaborate? >>> >>>> If there is only one MN, it may >>>> be OK but as more MNs join, especially in hot spots then the problems >>>> start. >>> >>> Why? Are you saying that the current link model for PMIP6 allows only a >>> single MN to attach to a WiFi AP (as an example)? >>> What is the basis for saying that having many MNs attach to a MAG in a >>> hotspot (assuming wifi) will result in problems? >>> Is there any work that you have done to make such a statement? >> >> >> As you know similar concerns have been voiced over and over again in Net= ext. >> >> Isn't it time to do something on this? >> >> Clarify that everything will work fine >> >> or >> >> if not, then propose solutions. >> >> If you look at SaMOG work in 3GPP, they repeatedly said WiFi should >> provide point to point link to UEs. >> >> Why do you think they said so if they anticipated no problems? >> >> Behcet >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From sgundave@cisco.com Fri Apr 27 09:46:01 2012 Return-Path: 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 4F2CD21F85F6 for ; Fri, 27 Apr 2012 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EoJAmT1Uyofb for ; Fri, 27 Apr 2012 09:46:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 68B9821F85EA for ; Fri, 27 Apr 2012 09:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5177; q=dns/txt; s=iport; t=1335545160; x=1336754760; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=IkE4gKH2LQ1sXs+cTgXitLqZlKZbK1hNFX674fYU9oo=; b=AK9Nsw1tmmojdkae25PsYXVOCE8CYTOvi8lVfrtSfVTRfDttANkcIjkA 0oMktOU8ScFRB4yQwlomJyEwQnhAOO5QMChFnk/ERbWvQ+wiQomQr1VT1 Z4R3W0GJzZaCwlQc2+3J3JP4Y98/eOlhXW0vZouF+7rhOjG2kNVgyHzu6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALLMmk+rRDoJ/2dsb2JhbABEsXCBB4IJAQEBAwEBAQEPAVsLBQsLEgYuIQYiDhkbB4ddAwYEDJwYlkcNiU8EigeGWWMEiGONGos9gxqBaYMI X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="39386629" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 27 Apr 2012 16:46:00 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3RGjxUu006810; Fri, 27 Apr 2012 16:45:59 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Sri Gundavelli In-Reply-To: Date: Fri, 27 Apr 2012 09:45:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A1B7670-5F4D-4421-AB24-FB6DC29D5CE9@cisco.com> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:46:01 -0000 > I wonder how do you map to a single receiver if there are more than > one receivers, i.e. the correct receiver? L3-Multicast, L2 unicast to a given node. RFC 6085. This is standard = stuff; There is no issue here. Sri On Apr 27, 2012, at 9:43 AM, Behcet Sarikaya wrote: > Hi Sri, >=20 > Thanks for chipping in your valuable views on this. > Basavaraj seems to disagree that there is a problem there but I don't = know why? >=20 > On Fri, Apr 27, 2012 at 11:15 AM, Sri Gundavelli = wrote: >> Hi Behcet: >>=20 >> Sorry to jump in to this thread. I'm going to respond/clarify only on = one specific comment (may be tangential to your discussion), as I'm not = following this thread/rest of the discussion. I want to clarify only = that one part though about WLAN, PMIPv6 and SaMOG. >>=20 >>=20 >>=20 >>>> Why? Are you saying that the current link model for PMIP6 allows = only a >>>> single MN to attach to a WiFi AP (as an example)? >>>> What is the basis for saying that having many MNs attach to a MAG = in a >>>> hotspot (assuming wifi) will result in problems? >>>> Is there any work that you have done to make such a statement? >>>=20 >>>=20 >>> As you know similar concerns have been voiced over and over again in = Netext. >>>=20 >>> Isn't it time to do something on this? >>>=20 >>> Clarify that everything will work fine >>=20 >>=20 >>=20 >> It is true, WLAN access is a shared media and what we need in Proxy >> Mobile IPv6 is essentially the ability for the MAG to advertise = unicast >> RA's/or in general keep multicast traffic map to a single receiver = (as >> clarified in RFC-6085). This is today the case on WLAN access >> networks. A client when it sends a multicast/broadcast packet, that >> packet is not sensed by the other receivers directly on the air = interface, >> as in the case of ethernet, but rather it hits the access point and = its the >> function if the access point to stream it down with using the correct >> multicast keys; this in essence is giving the model that we needed, = as l >> ong as the access point/WLC blocks multicast traffic from wireless >> clients from other wireless clients. All most every WLAN deployment = is >> typically configured to operate it this way. The SaMOG architecture = (or >> the WLAN IWK document that I've published), makes that assumption >> with impact to link model, else SaMOG architecture (with either of = S2a >> protocol interfaces) is broken and un deployable. >>=20 >=20 > I wonder how do you map to a single receiver if there are more than > one receivers, i.e. the correct receiver? >=20 > You mentioned WLAN IWK document, can you provide the link? >=20 > As you know there are also Layer 2 solutions. >=20 > I think we need to document it in Netext, maybe the chairs can add a > milestone on this to the charter? >=20 > Regards, >=20 > Behcet >=20 >=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Apr 27, 2012, at 8:34 AM, Behcet Sarikaya wrote: >>=20 >>> Hi Basavaraj, >>>=20 >>> Pls see inline. >>>=20 >>> On Thu, Apr 26, 2012 at 10:44 AM, = wrote: >>>>=20 >>>> Inline: >>>>=20 >>>> On 4/26/12 9:59 AM, "ext Behcet Sarikaya" = wrote: >>>>=20 >>>>> Hi Basavaraj, >>>>>=20 >>>>>>> 2. As I said above, the draft's main concern is MN = authentication on >>>>>>> Wi-Fi links. As we all know, PMIPv6 is based on point-to-point = links >>>>>>> and Wi-Fi link is a shared link. >>>>>>> Does this raise any concerns to you? >>>>>>=20 >>>>>> No. >>>>>=20 >>>>> Really? >>>>>=20 >>>>> Imagine MAG as defined in RFC 5213 (which assumes that each MN is = on a >>>>> point-to-point link) is connected to a shared link. >>>>=20 >>>> We all understand the link model requirements for PMIP6. Nothing is = being >>>> changed there. >>>>=20 >>>>> I think the result will be disastrous. >>>>=20 >>>> Why? Can you elaborate? >>>>=20 >>>>> If there is only one MN, it may >>>>> be OK but as more MNs join, especially in hot spots then the = problems >>>>> start. >>>>=20 >>>> Why? Are you saying that the current link model for PMIP6 allows = only a >>>> single MN to attach to a WiFi AP (as an example)? >>>> What is the basis for saying that having many MNs attach to a MAG = in a >>>> hotspot (assuming wifi) will result in problems? >>>> Is there any work that you have done to make such a statement? >>>=20 >>>=20 >>> As you know similar concerns have been voiced over and over again in = Netext. >>>=20 >>> Isn't it time to do something on this? >>>=20 >>> Clarify that everything will work fine >>>=20 >>> or >>>=20 >>> if not, then propose solutions. >>>=20 >>> If you look at SaMOG work in 3GPP, they repeatedly said WiFi should >>> provide point to point link to UEs. >>>=20 >>> Why do you think they said so if they anticipated no problems? >>>=20 >>> Behcet >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 From sarikaya2012@gmail.com Fri Apr 27 09:51:16 2012 Return-Path: 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 B4C0D21F8610 for ; Fri, 27 Apr 2012 09:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 RJlssTQV85cG for ; Fri, 27 Apr 2012 09:51:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7786B21F860E for ; Fri, 27 Apr 2012 09:51:15 -0700 (PDT) Received: by iazz13 with SMTP id z13so1537111iaz.31 for ; Fri, 27 Apr 2012 09:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=H/foICZ4Yufoq2TUbSMABcNJFTtmflDkh8tIHMm5tU0=; b=rlqATQV6TGJxZ9MN4/bUn71ilOQ9gf/JnQ9kCsUU7FuUtq8aCnTjX4+NKf9Hg+qNPh 1FTtZdIy+/pBpt4t18/23w1wzi1Q/FHG65iQGh3kPhMs/uQ+x6AdGyUShUDkkS/0tgqy FLcYzzBEUWye9rZsnH/jkp3QmWCLARv5zTJUJ6GOsX5RhF1LrtEjGqzjEywwwYnDiGYR Gl/RAhWjiD1jXnvV2nAfL8BeRmTmi7GX+aJPjpw0CBnghTOl3G/RShPEF/79yyLhsi3K eOjtUg/4n1X/5kCtqtyyuI6xerHgbbOV6xHY/9vsjZXQStj5IT9USQN6qbD0/JxedQsz SinQ== MIME-Version: 1.0 Received: by 10.50.47.162 with SMTP id e2mr3506659ign.0.1335545475098; Fri, 27 Apr 2012 09:51:15 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Fri, 27 Apr 2012 09:51:15 -0700 (PDT) In-Reply-To: <9A1B7670-5F4D-4421-AB24-FB6DC29D5CE9@cisco.com> References: <9A1B7670-5F4D-4421-AB24-FB6DC29D5CE9@cisco.com> Date: Fri, 27 Apr 2012 11:51:15 -0500 Message-ID: From: Behcet Sarikaya To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org 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, 27 Apr 2012 16:51:17 -0000 On Fri, Apr 27, 2012 at 11:45 AM, Sri Gundavelli wrote= : >> I wonder how do you map to a single receiver if there are more than >> one receivers, i.e. the correct receiver? > > L3-Multicast, L2 unicast to a given node. RFC 6085. This is standard stuf= f; There is no issue here. > I read RFC 6085. I had that question and I could not find an answer for that? How does the AP know "the given node"? Anyways, I repeat my plea for documenting this issue in Netext and clearing the air once and for all. Behcet > > > Sri > > > > > > > On Apr 27, 2012, at 9:43 AM, Behcet Sarikaya wrote: > >> Hi Sri, >> >> Thanks for chipping in your valuable views on this. >> Basavaraj seems to disagree that there is a problem there but I don't kn= ow why? >> >> On Fri, Apr 27, 2012 at 11:15 AM, Sri Gundavelli wr= ote: >>> Hi Behcet: >>> >>> Sorry to jump in to this thread. I'm going to respond/clarify only on o= ne specific comment (may be tangential to your discussion), as I'm not foll= owing this thread/rest of the discussion. I want to clarify only that one p= art though about WLAN, PMIPv6 and SaMOG. >>> >>> >>> >>>>> Why? Are you saying that the current link model for PMIP6 allows only= a >>>>> single MN to attach to a WiFi AP (as an example)? >>>>> What is the basis for saying that having many MNs attach to a MAG in = a >>>>> hotspot (assuming wifi) will result in problems? >>>>> Is there any work that you have done to make such a statement? >>>> >>>> >>>> As you know similar concerns have been voiced over and over again in N= etext. >>>> >>>> Isn't it time to do something on this? >>>> >>>> Clarify that everything will work fine >>> >>> >>> >>> It is true, WLAN access is a shared media and what we need in Proxy >>> Mobile IPv6 is essentially the ability for the MAG to advertise unicast >>> RA's/or in general keep multicast traffic map to a single receiver (as >>> clarified in RFC-6085). This is today the case on WLAN access >>> networks. A client when it sends a multicast/broadcast packet, that >>> packet is not sensed by the other receivers directly on the air interfa= ce, >>> as in the case of ethernet, but rather it hits the access point and its= the >>> function if the access point to stream it down with using the correct >>> multicast keys; this in essence is giving the model that we needed, as = l >>> ong as the access point/WLC blocks multicast traffic from wireless >>> clients from other wireless clients. =A0All most every WLAN deployment = is >>> typically configured to operate it this way. The SaMOG architecture (or >>> the WLAN IWK document that I've published), makes that assumption >>> with impact to link model, else SaMOG architecture (with either of S2a >>> protocol interfaces) is broken and un deployable. >>> >> >> I wonder how do you map to a single receiver if there are more than >> one receivers, i.e. the correct receiver? >> >> You mentioned WLAN IWK document, can you provide the link? >> >> As you know there are also Layer 2 solutions. >> >> I think we need to document it in Netext, maybe the chairs can add a >> milestone on this to the charter? >> >> Regards, >> >> Behcet >> >> >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> >>> >>> On Apr 27, 2012, at 8:34 AM, Behcet Sarikaya wrote: >>> >>>> Hi Basavaraj, >>>> >>>> Pls see inline. >>>> >>>> On Thu, Apr 26, 2012 at 10:44 AM, =A0 wrote= : >>>>> >>>>> Inline: >>>>> >>>>> On 4/26/12 9:59 AM, "ext Behcet Sarikaya" wr= ote: >>>>> >>>>>> Hi Basavaraj, >>>>>> >>>>>>>> 2. As I said above, the draft's main concern is MN authentication = on >>>>>>>> Wi-Fi links. As we all know, PMIPv6 is based on point-to-point lin= ks >>>>>>>> and Wi-Fi link is a shared link. >>>>>>>> Does this raise any concerns to you? >>>>>>> >>>>>>> No. >>>>>> >>>>>> Really? >>>>>> >>>>>> Imagine MAG as defined in RFC 5213 (which assumes that each MN is on= a >>>>>> point-to-point link) is connected to a shared link. >>>>> >>>>> We all understand the link model requirements for PMIP6. Nothing is b= eing >>>>> changed there. >>>>> >>>>>> I think the result will be disastrous. >>>>> >>>>> Why? Can you elaborate? >>>>> >>>>>> If there is only one MN, it may >>>>>> be OK but as more MNs join, especially in hot spots then the problem= s >>>>>> start. >>>>> >>>>> Why? Are you saying that the current link model for PMIP6 allows only= a >>>>> single MN to attach to a WiFi AP (as an example)? >>>>> What is the basis for saying that having many MNs attach to a MAG in = a >>>>> hotspot (assuming wifi) will result in problems? >>>>> Is there any work that you have done to make such a statement? >>>> >>>> >>>> As you know similar concerns have been voiced over and over again in N= etext. >>>> >>>> Isn't it time to do something on this? >>>> >>>> Clarify that everything will work fine >>>> >>>> or >>>> >>>> if not, then propose solutions. >>>> >>>> If you look at SaMOG work in 3GPP, they repeatedly said WiFi should >>>> provide point to point link to UEs. >>>> >>>> Why do you think they said so if they anticipated no problems? >>>> >>>> Behcet >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> > From sgundave@cisco.com Fri Apr 27 09:53:10 2012 Return-Path: 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 15A9F21F875C for ; Fri, 27 Apr 2012 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.827 X-Spam-Level: X-Spam-Status: No, score=-9.827 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 ksiyMQc3ru6i for ; Fri, 27 Apr 2012 09:53:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 200D721F875A for ; Fri, 27 Apr 2012 09:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6148; q=dns/txt; s=iport; t=1335545589; x=1336755189; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=03ayKTsdfDX8fUr1BzTVPXmkIMoT7CQlepcO/loPtg0=; b=P01vxPUeEkx44HQ3tbYvTY0yPLRaj7qgVCbrYpooz7zhrEgDO8gnJnbX wST/NEwaRalnFNQ0GdgQ+Aw4j56TFZr9eReG998zlZZcAzzH4h7oVWxCb IbVWWneCefKOQt9qXOleXcVGKzY5rHYaQ6jPor8ESTUAD/JffgawD2yfD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8KAALOmk+rRDoJ/2dsb2JhbAA7CbBUA4EZgQeCCQEBAQMBAQEBDwEpATELBQ0BCBIGTwYiDgEBBA4FGweHXQMGBAELnBeWRw2JTwSKB3iBCoU6BIgvNI0aiz2DGoFpgwg X-IronPort-AV: E=Sophos;i="4.75,492,1330905600"; d="scan'208";a="42501510" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 27 Apr 2012 16:53:08 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3RGr8B0011242; Fri, 27 Apr 2012 16:53:08 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 09:53:08 -0700 Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Apr 2012 16:53:08 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 27 Apr 2012 09:53:05 -0700 From: Sri Gundavelli To: Message-ID: Thread-Topic: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt Thread-Index: Ac0kljb/IFuKuHgb1EiVoUTc2PUnng== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Apr 2012 16:53:08.0529 (UTC) FILETIME=[3919AA10:01CD2496] Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:53:10 -0000 Mac address is bound to the EAP identity. The Wireless LAN Controller/Acces= s Point has the Mac to identity binding, which has association in the BUL entry. Sri On 4/27/12 9:51 AM, "Behcet Sarikaya" wrote: > On Fri, Apr 27, 2012 at 11:45 AM, Sri Gundavelli wro= te: >>> I wonder how do you map to a single receiver if there are more than >>> one receivers, i.e. the correct receiver? >>=20 >> L3-Multicast, L2 unicast to a given node. RFC 6085. This is standard stu= ff; >> There is no issue here. >>=20 >=20 > I read RFC 6085. >=20 > I had that question and I could not find an answer for that? How does > the AP know "the given node"? >=20 > Anyways, I repeat my plea for documenting this issue in Netext and > clearing the air once and for all. >=20 > Behcet >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Apr 27, 2012, at 9:43 AM, Behcet Sarikaya wrote: >>=20 >>> Hi Sri, >>>=20 >>> Thanks for chipping in your valuable views on this. >>> Basavaraj seems to disagree that there is a problem there but I don't k= now >>> why? >>>=20 >>> On Fri, Apr 27, 2012 at 11:15 AM, Sri Gundavelli w= rote: >>>> Hi Behcet: >>>>=20 >>>> Sorry to jump in to this thread. I'm going to respond/clarify only on = one >>>> specific comment (may be tangential to your discussion), as I'm not >>>> following this thread/rest of the discussion. I want to clarify only t= hat >>>> one part though about WLAN, PMIPv6 and SaMOG. >>>>=20 >>>>=20 >>>>=20 >>>>>> Why? Are you saying that the current link model for PMIP6 allows onl= y a >>>>>> single MN to attach to a WiFi AP (as an example)? >>>>>> What is the basis for saying that having many MNs attach to a MAG in= a >>>>>> hotspot (assuming wifi) will result in problems? >>>>>> Is there any work that you have done to make such a statement? >>>>>=20 >>>>>=20 >>>>> As you know similar concerns have been voiced over and over again in >>>>> Netext. >>>>>=20 >>>>> Isn't it time to do something on this? >>>>>=20 >>>>> Clarify that everything will work fine >>>>=20 >>>>=20 >>>>=20 >>>> It is true, WLAN access is a shared media and what we need in Proxy >>>> Mobile IPv6 is essentially the ability for the MAG to advertise unicas= t >>>> RA's/or in general keep multicast traffic map to a single receiver (as >>>> clarified in RFC-6085). This is today the case on WLAN access >>>> networks. A client when it sends a multicast/broadcast packet, that >>>> packet is not sensed by the other receivers directly on the air interf= ace, >>>> as in the case of ethernet, but rather it hits the access point and it= s the >>>> function if the access point to stream it down with using the correct >>>> multicast keys; this in essence is giving the model that we needed, as= l >>>> ong as the access point/WLC blocks multicast traffic from wireless >>>> clients from other wireless clients. =A0All most every WLAN deployment i= s >>>> typically configured to operate it this way. The SaMOG architecture (o= r >>>> the WLAN IWK document that I've published), makes that assumption >>>> with impact to link model, else SaMOG architecture (with either of S2a >>>> protocol interfaces) is broken and un deployable. >>>>=20 >>>=20 >>> I wonder how do you map to a single receiver if there are more than >>> one receivers, i.e. the correct receiver? >>>=20 >>> You mentioned WLAN IWK document, can you provide the link? >>>=20 >>> As you know there are also Layer 2 solutions. >>>=20 >>> I think we need to document it in Netext, maybe the chairs can add a >>> milestone on this to the charter? >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Regards >>>> Sri >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Apr 27, 2012, at 8:34 AM, Behcet Sarikaya wrote: >>>>=20 >>>>> Hi Basavaraj, >>>>>=20 >>>>> Pls see inline. >>>>>=20 >>>>> On Thu, Apr 26, 2012 at 10:44 AM, =A0 wrote: >>>>>>=20 >>>>>> Inline: >>>>>>=20 >>>>>> On 4/26/12 9:59 AM, "ext Behcet Sarikaya" w= rote: >>>>>>=20 >>>>>>> Hi Basavaraj, >>>>>>>=20 >>>>>>>>> 2. As I said above, the draft's main concern is MN authentication= on >>>>>>>>> Wi-Fi links. As we all know, PMIPv6 is based on point-to-point li= nks >>>>>>>>> and Wi-Fi link is a shared link. >>>>>>>>> Does this raise any concerns to you? >>>>>>>>=20 >>>>>>>> No. >>>>>>>=20 >>>>>>> Really? >>>>>>>=20 >>>>>>> Imagine MAG as defined in RFC 5213 (which assumes that each MN is o= n a >>>>>>> point-to-point link) is connected to a shared link. >>>>>>=20 >>>>>> We all understand the link model requirements for PMIP6. Nothing is = being >>>>>> changed there. >>>>>>=20 >>>>>>> I think the result will be disastrous. >>>>>>=20 >>>>>> Why? Can you elaborate? >>>>>>=20 >>>>>>> If there is only one MN, it may >>>>>>> be OK but as more MNs join, especially in hot spots then the proble= ms >>>>>>> start. >>>>>>=20 >>>>>> Why? Are you saying that the current link model for PMIP6 allows onl= y a >>>>>> single MN to attach to a WiFi AP (as an example)? >>>>>> What is the basis for saying that having many MNs attach to a MAG in= a >>>>>> hotspot (assuming wifi) will result in problems? >>>>>> Is there any work that you have done to make such a statement? >>>>>=20 >>>>>=20 >>>>> As you know similar concerns have been voiced over and over again in >>>>> Netext. >>>>>=20 >>>>> Isn't it time to do something on this? >>>>>=20 >>>>> Clarify that everything will work fine >>>>>=20 >>>>> or >>>>>=20 >>>>> if not, then propose solutions. >>>>>=20 >>>>> If you look at SaMOG work in 3GPP, they repeatedly said WiFi should >>>>> provide point to point link to UEs. >>>>>=20 >>>>> Why do you think they said so if they anticipated no problems? >>>>>=20 >>>>> Behcet >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>=20 >>=20 From denghui02@gmail.com Fri Apr 27 18:22:45 2012 Return-Path: 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 DBD6921E801E for ; Fri, 27 Apr 2012 18:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 a1OzQHrkFLty for ; Fri, 27 Apr 2012 18:22:44 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8B33321E802B for ; Fri, 27 Apr 2012 18:22:44 -0700 (PDT) Received: by yhgm50 with SMTP id m50so1179642yhg.27 for ; Fri, 27 Apr 2012 18:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GO7uJzr+r44ef3AC3CFPRim6mab51wS41rG49Pikiss=; b=v08W/Wi8PjJB+510wSFyAkkEYh7gJdj8Taw4qXDhLefMV5eRWRYQfw7ff3bza9JXHj bSriUiwfguH5xyq8VqLEU6cqqHWSScKlYU2zNSGPzmlaWmuSblRL6MP3/PyO2LBL2/nS 9F1PvhCBKpDAoajFmK/Tyb8VxAU+zI+I76GzVdzWQ27w4KCcVtsF0dmvVT8uqukhTNy5 cH2GWv3AwHqeCW1/sNJGQRIDKcgsAAR/OJU0PmjtvjwNnIm5NZpGdYqnwaxv4SHANgnC mUb8adzPs92iVQ+xgTyNmeIsFcr3li/c3MmwuPwSmv512vDF8zcKuTrIb809HVTL38Pw d07Q== MIME-Version: 1.0 Received: by 10.236.145.34 with SMTP id o22mr14076315yhj.7.1335576164092; Fri, 27 Apr 2012 18:22:44 -0700 (PDT) Received: by 10.147.115.6 with HTTP; Fri, 27 Apr 2012 18:22:44 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202520FB4@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C46202520F26@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C46202520FB4@ftrdmel0.rd.francetelecom.fr> Date: Sat, 28 Apr 2012 09:22:44 +0800 Message-ID: From: Hui Deng To: pierrick.seite@orange.com Content-Type: multipart/alternative; boundary=20cf303b3cdfd4cc6304beb30e73 Cc: netext@ietf.org Subject: Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 01:22:46 -0000 --20cf303b3cdfd4cc6304beb30e73 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pierrick, in previous email, you were saying that the purpose of delivering parameters related to 3GPP air-interface like ARP, GDBR, GUBR is for mapping to DSCP, then I asked you are also delivering DSCP. and then you explained why DSCP is needed then, my question has to go back, why you need to deliver parameters related to 3GPP air-interface like ARP, GDBR, GUBR, is that for the purpose of S5/S8 other than WLAN, or it is also for the WLAN thanks for the discussion -Hui 2012/4/27 > Hi Hui,**** > > ** ** > > Please see inline**** > > ** ** > > Pierrick**** > > ** ** > > *De :* Hui Deng [mailto:denghui02@gmail.com] > *Envoy=E9 :* vendredi 27 avril 2012 15:37 > *=C0 :* SEITE Pierrick RD-RESA-REN > *Cc :* netext@ietf.org > *Objet :* Re: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt*= * > ** > > ** ** > > Pierrick, **** > > **** > > thanks for your quick response,**** > > **** > > but you also deliver dscp as well?**** > > ** ** > > Yes, the QoS option shall at least include a dscp. If QoS policy is a 3GP= P > policy, the LMA relies on default QCI/DSCP mapping as explained in sectio= n > 3.4. Optional qos parameters may be used by the wi-fi access network to d= o > its own mapping, but this is out of scope of the current document. The > other reason to include a DSCP is that the QoS option may be used in > another context that 3GPP/Wi-Fi, we have to document this use-case. **** > > ** ** > > **** > > -Hui**** > > 2012/4/27 **** > > Hi Hui,**** > > **** > > Thanks for the feedback. **** > > **** > > Actually, parameters like , ARP, GDBR, GUBR are optional in the QoS > option. You=92re right, this is 3GPP QoS policy parameters but they can b= e > provisioned to the wifi network in a 3GPP/wi-fi interworking context. And > using the PMIP QoS option if we assume that the wi-fi access has no PCC. = In > this situation, the mobile network (here LMA) provides the QoS policies, = in > a 3GPP format, to the wi-fi access network (here the MAG) which is suppos= ed > to do the mapping to DSCP policies that a wifi network used to manage.***= * > > **** > > Hope that clarifies.**** > > **** > > BR,**** > > Pierrick**** > > **** > > *De :* netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] *De la > part de* Hui Deng > *Envoy=E9 :* vendredi 27 avril 2012 13:16 > *=C0 :* netext@ietf.org > *Objet :* [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt**** > > **** > > Hello authors, **** > > **** > > I have read through document, want to clarify below:**** > > **** > > In the section 6, many parameters related to 3GPP air-interface has been > spcified like ARP, GDBR, GUBR,**** > > because wifi today doesn't have such capability, just wan to know whether > you would like to extend WLC capability**** > > to support and make wifi a much better wireless technology:)**** > > **** > > If PMIP6 historically doesn't QoS, is that PCC will not be able to use fo= r > PMIP6 based S5/S8 interfaces?**** > > **** > > thanks for writing this document.**** > > **** > > Best,**** > > **** > > -Hui**** > > 2012/4/26 Sri Gundavelli **** > > Folks: > > Please comment on this draft. Lot of efforts went in to this from all the > Authors, please review and comment. > > http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > > > Regards > Sri **** > > > > > > On 3/13/12 8:40 AM, "Marco Liebsch" wrote:**** > > Please find an update of our draft about a QoS option for PMIP6 on the > IETF repository, which > addresses comments from last meeting. The current version includes more > details about the > proposed operation and QoS attributes. > > Marco > > Filename: draft-liebsch-netext-pmip6-qos > Revision: 01 > Title: Quality of Service Option for Proxy Mobile IP= v6 > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 32 > Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > Abstract: > This specification defines a new mobility option that can be used by > the mobility entities in the Proxy Mobile IPv6 domain to exchange > Quality of Service parameters associated with a subscriber's IP > flows. Using the QoS option, the local mobility anchor and the > mobile access gateway can exchange available QoS attributes and > associated values. This enables QoS policing and labeling of packets > to enforce QoS differentiation on the path between the local mobility > anchor and the mobile access gateway. Furthermore, making QoS > parameters available on the MAG enables mapping these parameters to > QoS rules being specific to the access technology which operates > below the mobile access gateway. After such mapping, QoS rules can > be enforced on the access technology components, such as an IEEE > 802.11e Wireless LAN controller. > > **** > ------------------------------ > > _______________________________________________ > 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**** > > **** > > ** ** > --20cf303b3cdfd4cc6304beb30e73 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Pierrick,
=A0
in previous email, you=A0= were saying that the purpose of delivering parameters related to 3GPP air-i= nterface like ARP, GDBR, GUBR is for mapping to DSCP, then I asked you are = also delivering DSCP. and then you explained why DSCP is needed
=A0
then, my question has to=A0go back, why you need= to deliver parameters related to 3GPP air-interface like ARP, GDBR, GUBR, = is that for the purpose of S5/S8 other than WLAN, or it is also for the WLA= N
=A0
thanks for the discussion
=A0
-Hui

2012/4/27 <pierrick.seite@orange.com>

Hi Hui,

=A0

Please see inline=

=A0

Pierrick<= u>

=A0

=A0

Pierrick,

=A0

thanks for your quick response,

=A0

but you also deliver dscp as well?

=A0

Yes, the QoS opt= ion shall at least include a dscp. If QoS policy is a 3GPP policy, the LMA = relies on default QCI/DSCP mapping as explained in section 3.4. Optional qo= s parameters may be used by the wi-fi access network to do its own mapping,= but this is out of scope of the current document. The other reason to incl= ude a DSCP is that the QoS option may be used in another context that 3GPP/= Wi-Fi, we have to document this use-case.

=A0

=A0

-Hui

<= /div>

2012/4/27 <pierrick.seite@orange.com>

Hi Hui,

=A0

Thanks for the f= eedback.

=A0

Actually, parame= ters like , ARP, GDBR, GUBR are optional in the QoS option. You=92re right,= this is 3GPP QoS policy parameters but they can be provisioned to the wifi= network in a 3GPP/wi-fi interworking context. And using the PMIP QoS optio= n if we assume that the wi-fi access has no PCC. In this situation, the mob= ile network (here LMA) provides the QoS policies, in a 3GPP format, to the = wi-fi access network (here the MAG) which is supposed to do the mapping to = DSCP policies that a wifi network used to manage.

=A0

Hope that clarif= ies.

=A0

BR,

Pierrick<= u>

=A0

De=A0: netext-bounces@ietf.org [mail= to:netext-boun= ces@ietf.org] De la part de Hui Deng
Envoy=E9=A0: vendredi 27 avril 2012 13:16
=C0=A0: netext@ietf.org
Obj= et=A0: [netext] Comments on draft-liebsch-netext-pmip6-qos-01.txt

=A0

Hello authors,

=A0

I have read through document, want to clarify below:=

=A0

In the section 6, many parameters related to 3GPP ai= r-interface has been spcified like ARP, GDBR, GUBR,

because wifi today doesn't have such capability,= just wan to know whether you would like to extend WLC capability=

to support and make wifi a much better wireless tech= nology:)

=A0

If PMIP6 historically doesn't QoS, is that PCC w= ill not be able to use for PMIP6 based S5/S8 interfaces?

<= /div>

=A0

thanks for writing this=A0document.

=A0

Best,

=A0

-Hui

<= /div>

2012/4/26 Sri Gundavelli <sgundave@cisco.com>

Folks:

Please comment on this draft. L= ot of efforts went in to this from all the Authors, please review and comme= nt.

http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-0= 1.txt



Regards
Sri





= On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:<= /span>

Please find an u= pdate of our draft about a QoS option for PMIP6 on the IETF repository, whi= ch
addresses comments from last meeting. The current version includes more det= ails about the
proposed operation and QoS attributes.
=A0
Marco=A0
Filename: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0draft-liebsch-netext-pm= ip6-qos
Revision: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A001
Title: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Quali= ty of Service Option for Proxy Mobile IPv6
Creation date: =A0=A02012-03-= 12
WG ID: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Individual = Submission
Number of pages: 32
Link: http://www.ietf.= org/id/draft-liebsch-netext-pmip6-qos-01.txt
=A0
Abstract:
=A0=A0=A0This specification defines a new mobility opti= on that can be used by
=A0=A0=A0the mobility entities in the Proxy Mobil= e IPv6 domain to exchange
=A0=A0=A0Quality of Service parameters associa= ted with a subscriber&#39;s IP
=A0=A0=A0flows. =A0Using the QoS option, the local mobility anchor and the<= br>=A0=A0=A0mobile access gateway can exchange available QoS attributes and=
=A0=A0=A0associated values. =A0This enables QoS policing and labeling o= f packets
=A0=A0=A0to enforce QoS differentiation on the path between th= e local mobility
=A0=A0=A0anchor and the mobile access gateway. =A0Furthermore, making QoS=A0=A0=A0parameters available on the MAG enables mapping these parameters= to
=A0=A0=A0QoS rules being specific to the access technology which ope= rates
=A0=A0=A0below the mobile access gateway. =A0After such mapping, Q= oS rules can
=A0=A0=A0be enforced on the access technology components, such as an IEEE=A0=A0=A0802.11e Wireless LAN controller.
=A0
=A0<= /u>

= _______________________________________________
netext mailing list
<= a href=3D"http://netext@ietf.org" target=3D"_blank">netext@ietf.org
= = https://www.ietf.org/mailman/listinfo/netext


___________________= ____________________________
netext mailing list
netext@ietf.org
https://www.ietf.or= g/mailman/listinfo/netext

=A0

<= /div>

=A0

<= /div>

--20cf303b3cdfd4cc6304beb30e73-- From internet-drafts@ietf.org Sun Apr 29 01:40:49 2012 Return-Path: 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 6D41721F853D; Sun, 29 Apr 2012 01:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, 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 yRQ5l+xOuFw3; Sun, 29 Apr 2012 01:40:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DD521F84D5; Sun, 29 Apr 2012 01:40:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120429084048.15825.64421.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 01:40:48 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 08:40:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Wor= king Group of the IETF. Title : Logical Interface Support for multi-mode IP Hosts Author(s) : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-05.txt Pages : 25 Date : 2012-04-29 A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-sup= port-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-supp= ort-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-suppor= t/ From yiu_lee@cable.comcast.com Sun Apr 29 12:59:23 2012 Return-Path: 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 9700221F8499 for ; Sun, 29 Apr 2012 12:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.723 X-Spam-Level: X-Spam-Status: No, score=-99.723 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, MIME_QP_LONG_LINE=1.396, 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 ikopm+bkf2VE for ; Sun, 29 Apr 2012 12:59:22 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8503321F8478 for ; Sun, 29 Apr 2012 12:59:22 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.15303989; Sun, 29 Apr 2012 13:45:15 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Sun, 29 Apr 2012 15:59:17 -0400 From: "Lee, Yiu" Thread-Topic: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt Thread-Index: AQHNJkKOMUJgnS7HZEKvhG0oy4yc8Q== Date: Sun, 29 Apr 2012 19:59:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3418559953_10027601" MIME-Version: 1.0 To: Sri Gundavelli , Marco Liebsch , "netext@ietf.org" Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 19:59:23 -0000 --B_3418559953_10027601 Content-type: multipart/alternative; boundary="B_3418559953_10005223" --B_3418559953_10005223 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, I read this draft and I think is an important aspect missing in PMIPv6. I think the WG should seriously consider to work on it. In the current version, I have a concern. For example: Fig 3.5.1 shows the LMA will include the QoS option in PBA. If the MAG can't satisfy the QoS, what will the MAG do? Dereg the session? PBA is an acknowledgement to the PBU. It looks odd to me to use it for carrying QoS request.r Perhaps a better way to handle it is to create a new set of QoS request/response rather than embedding the QoS request in the PBA. Thanks, Yiu From: Sri Gundavelli Date: Wednesday, April 25, 2012 7:31 PM To: Marco Liebsch , "netext@ietf.org" Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt Folks: Please comment on this draft. Lot of efforts went in to this from all the Authors, please review and comment. http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt Regards Sri On 3/13/12 8:40 AM, "Marco Liebsch" wrote: > Please find an update of our draft about a QoS option for PMIP6 on the IETF > repository, which > addresses comments from last meeting. The current version includes more > details about the > proposed operation and QoS attributes. > > Marco > > Filename: draft-liebsch-netext-pmip6-qos > Revision: 01 > Title: Quality of Service Option for Proxy Mobile IPv6 > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 32 > Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt > > Abstract: > This specification defines a new mobility option that can be used by > the mobility entities in the Proxy Mobile IPv6 domain to exchange > Quality of Service parameters associated with a subscriber's IP > flows. Using the QoS option, the local mobility anchor and the > mobile access gateway can exchange available QoS attributes and > associated values. This enables QoS policing and labeling of packets > to enforce QoS differentiation on the path between the local mobility > anchor and the mobile access gateway. Furthermore, making QoS > parameters available on the MAG enables mapping these parameters to > QoS rules being specific to the access technology which operates > below the mobile access gateway. After such mapping, QoS rules can > be enforced on the access technology components, such as an IEEE > 802.11e Wireless LAN controller. > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --B_3418559953_10005223 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,

I read this draft and I think is an important aspect missing in PMIPv6. I t= hink the WG should seriously consider to work on it. 

In the current version, I have a conc= ern. For example: Fig 3.5.1 shows the LMA will include the QoS opt= ion in PBA. If the MAG can't satisfy the QoS, what will the MAG do? Dereg th= e session? PBA is an acknowledgement to the PBU. It looks odd to= me to use it for carrying QoS request.r &nbs= p;Perhaps a better way to handle it is to create a new set of QoS request/re= sponse rather than embedding the QoS request in the PBA. 
<= div>
Thanks,
Yiu


=
From: Sri Gundavelli <sgundave@cisco.com>
Date: Wednesday, April 25, 2012 7:31 PM
To: Marco Liebsch <Marco.Liebsch@neclab.eu>, "ne= text@ietf.org" <netext@ietf.org&= gt;
Subject: Re: [netext] New Vers= ion Notification for draft-liebsch-netext-pmip6-qos-01.txt
 --B_3418559953_10005223-- --B_3418559953_10027601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQtPy9Y bIveV7RHkeubnkxHZIK4fzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA0MjkxOTU5MTNaMA0GCSqGSIb3DQEBAQUABIIBALsyI1B/DR0HWtCoHGajnLrL GeuvDvosi6Dx0Bx0ayLwMGGtDbime2yrIKcD+LPWNtA88UurrDtb7YmCd6EhYrsWWxuHH54L h0gdvDMruCescE2fYy+vhX8KZzFFqBIziAixKxpuH54vf2fmzVapikRkx1yNqSElveMFD2o1 sSJkN2IFFCy8Rp5OUe8WtrJpiYowGt/OK7QfnxkLbkaG3TC8bupLB8yMya4WnkiMPgyLKI/y iP9hufuR0ANxaCv6/TP5l8LNFSUk4kHJb/xCeBMaxCQvUoyXdsjy1qhnXdviUyrs+mdg9YN6 /alHFT6/+eD72lx7j7CgoWfnacMoMH8= --B_3418559953_10027601-- From Basavaraj.Patil@nokia.com Mon Apr 30 12:32:50 2012 Return-Path: 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 BAB7021E804B for ; Mon, 30 Apr 2012 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 b6aA3eSszHOb for ; Mon, 30 Apr 2012 12:32:50 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1158D21E804E for ; Mon, 30 Apr 2012 12:32:49 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3UJWmUY016107 for ; Mon, 30 Apr 2012 22:32:48 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 22:32:47 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Mon, 30 Apr 2012 21:32:46 +0200 From: To: Thread-Topic: Review request: draft-ietf-netext-logical-interface-support-05.txt Thread-Index: AQHNJwgFJLSTk+ineU+0reUvn8X1sg== Date: Mon, 30 Apr 2012 19:32:46 +0000 Message-ID: In-Reply-To: <20120429084048.15825.64421.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C12D99D4D9E5D459EC2CD38693EF9CB@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2012 19:32:47.0658 (UTC) FILETIME=[05F200A0:01CD2708] X-Nokia-AV: Clean Subject: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:32:50 -0000 Hello, The authors have revised the I-D and addressed concerns that have been previously raised.=20 We (chairs) would like WG members to review the I-D and provide feedback via the mailing list. Please make an effort and do a review of this I-D. -Chairs On 4/29/12 3:40 AM, "ext internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Network-Based Mobility >Extensions Working Group of the IETF. > > Title : Logical Interface Support for multi-mode IP Hosts > Author(s) : Telemaco Melia > Sri Gundavelli > Filename : draft-ietf-netext-logical-interface-support-05.txt > Pages : 25 > Date : 2012-04-29 > > A Logical Interface is a software semantic internal to the host > operating system. This semantic is available in all popular > operating systems and is used in various protocol implementations. > The Logical Interface support is required on the mobile node > operating in a Proxy Mobile IPv6 domain, for leveraging various > network-based mobility management features such as inter-technology > handoffs, multihoming and flow mobility support. This document > explains the operational details of Logical Interface construct and > the specifics on how the link-layer implementations hide the physical > interfaces from the IP stack and from the network nodes on the > attached access networks. Furthermore, this document identifies the > applicability of this approach to various link-layer technologies and > analyzes the issues around it when used in context with various > mobility management features. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-su >pport-05.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-sup >port-05.txt > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-suppo >rt/ > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From Peter.McCann@huawei.com Mon Apr 30 13:53:35 2012 Return-Path: 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 3CDE421E809E for ; Mon, 30 Apr 2012 13:53:34 -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=[AWL=0.000, BAYES_00=-2.599] 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 gJEDgfTTx3yu for ; Mon, 30 Apr 2012 13:53:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3899021E8019 for ; Mon, 30 Apr 2012 13:53:32 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFS39142; Mon, 30 Apr 2012 16:53:32 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 13:51:48 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 13:51:45 -0700 From: Peter McCann To: "Basavaraj.Patil@nokia.com" , "netext@ietf.org" Thread-Topic: Review request: draft-ietf-netext-logical-interface-support-05.txt Thread-Index: AQHNJwgFJLSTk+ineU+0reUvn8X1spaz1sqw Date: Mon, 30 Apr 2012 20:51:45 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716DF7B41@dfweml512-mbx.china.huawei.com> References: <20120429084048.15825.64421.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 20:53:35 -0000 I see the additional discussion of multiple provisioning domains in Section= 5.6, but I am still not completely happy. The text seems to imply that all phys= ical interfaces belonging to a single logical interface MUST belong to the same provisioning domain. While this might be true for some types of handovers, I think it is possible for a particular interface to be part of a different provisioning domain at other times. For example, I don't want my WiFi hard= ware to be always tied up with my 3G interface. There are times when I want to= =20 use my WiFi interface to connect to a network other than my 3G provider. You say in another place that physical interfaces can be added/deleted dyna= mically from the logical interface, but how do you know when you should do that? C= an you look at router advertisements or something and tell when you are in the same provisioning domain and when you are not? I think some more discussio= n on this topic is warranted. -Pete Basavaraj.Patil@nokia.com wrote: >=20 > Hello, >=20 > The authors have revised the I-D and addressed concerns that have been > previously raised. > We (chairs) would like WG members to review the I-D and provide > feedback via the mailing list. >=20 > Please make an effort and do a review of this I-D. >=20 > -Chairs >=20 > On 4/29/12 3:40 AM, "ext internet-drafts@ietf.org" > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Network-Based Mobility >> Extensions Working Group of the IETF. >>=20 >> Title : Logical Interface Support for multi-mode IP Hosts >> Author(s) : Telemaco Melia >> Sri Gundavelli >> Filename : draft-ietf-netext-logical-interface-support- 05.txt >> Pages : 25 Date : 2012-04-29 >>=20 >> A Logical Interface is a software semantic internal to the host >> operating system. This semantic is available in all popular >> operating systems and is used in various protocol implementations. >> The Logical Interface support is required on the mobile node >> operating in a Proxy Mobile IPv6 domain, for leveraging various >> network-based mobility management features such as inter-technology >> handoffs, multihoming and flow mobility support. This document >> explains the operational details of Logical Interface construct and >> the specifics on how the link-layer implementations hide the physical >> interfaces from the IP stack and from the network nodes on the >> attached access networks. Furthermore, this document identifies the >> applicability of this approach to various link-layer technologies and >> analyzes the issues around it when used in context with various >> mobility management features. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical- >> interface -su pport-05.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical- >> interface- sup port-05.txt >>=20 >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface- >> su ppo rt/ >>=20 >> _______________________________________________ >> 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 From Basavaraj.Patil@nokia.com Mon Apr 30 14:13:16 2012 Return-Path: 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 8B9B821F8603 for ; Mon, 30 Apr 2012 14:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 5Bh2CDTrbwTF for ; Mon, 30 Apr 2012 14:13:14 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id B9ABA21F85F6 for ; Mon, 30 Apr 2012 14:13:14 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3ULDDtZ029467 for ; Tue, 1 May 2012 00:13:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 00:13:12 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Mon, 30 Apr 2012 23:13:12 +0200 From: To: Thread-Topic: Questions on: draft-ietf-netext-logical-interface-support-05.txt Thread-Index: AQHNJxYMMu/A+bLcNEmdVxwqAA1fFg== Date: Mon, 30 Apr 2012 21:13:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <083B154B73631245B85FAE070FE052E0@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2012 21:13:12.0762 (UTC) FILETIME=[0D2FE9A0:01CD2716] X-Nokia-AV: Clean Subject: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:13:16 -0000 A few questions that come to mind: 1. Sec 6.2 discusses inter-technology handovers. What happens in the scenario of a break-before-make handover? Interface 1 goes down and there is a brief interval before another interface (2) becomes active. How does the logical interface behave in such a scenario? Do you still maintain the existing connections? The LIF may not have any awareness of whether another physical interface will be activated. 2. Regarding path MTU, the I-D says that in the case where the MN is attached simultaneously to multiple interfaces, the LIF will choose the smaller of the MTU values of the physical interfaces. However the I-D also says that the LIF has awareness of forwarding packets on the interface from which a packet was received. If that is the case, why would the LIF be configured with the lower value MTU? The LIF should be able to choose the appropriate MTU for sending a packet depending on the interface over which the packet is sent/received. 3. The statement: "The logical interface adapts to the point-to-point link model." is not completely clear. What exactly is the LIF adapting to? 4. Sec 3.2 is unclear. Please elaborate on the requirements and applicability. -Raj=20 From julien.ietf@gmail.com Mon Apr 30 16:29:42 2012 Return-Path: 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 64C9321E80F8 for ; Mon, 30 Apr 2012 16:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gfaXTTAFJL0b for ; Mon, 30 Apr 2012 16:29:41 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5590721E80F6 for ; Mon, 30 Apr 2012 16:29:41 -0700 (PDT) Received: by dady13 with SMTP id y13so6249933dad.27 for ; Mon, 30 Apr 2012 16:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qk2+39LaGPXHfnveNrRdaAJDra0Ruxk7xU1GWrS5TYQ=; b=iaa6kPHUaM4w1L8Qb/0LROIglFU29AeTmM+3mvr9/wMMh7rJ8woADgOqwsDutsKCgZ ZD5yD3ZOp0UFu9NELHWzhMlzFXQ4Cbw16+mTqZ6iPryT1soOufbdwajS6a1TajiiXoLg 0YO3R+iUqu6WuHQrSBI4p0wffiL5vSsW9qviy5xbCfJIT4xVxYU4vVS6nE9zhM/SKHoj MiYLgnzmtcbLHMnFSsb1pfLQ6dIcfaXyOQERzQBpjiskg5pdLACNJMdigw+Sk/jkJrDt XAYT14AaSBdmtzMcVWMR7QDDkp3jV8R2ivOAt3Qr7lYrbsCRAkG6cCWqEYj6tQqK9Rug ankQ== MIME-Version: 1.0 Received: by 10.68.228.106 with SMTP id sh10mr52012717pbc.107.1335828581117; Mon, 30 Apr 2012 16:29:41 -0700 (PDT) Received: by 10.68.63.166 with HTTP; Mon, 30 Apr 2012 16:29:41 -0700 (PDT) In-Reply-To: References: <20120429084048.15825.64421.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 16:29:41 -0700 Message-ID: From: Julien Laganier To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 23:29:42 -0000 On Mon, Apr 30, 2012 at 12:32 PM, wrote: > > Please make an effort and do a review of this I-D. I have reviewed this document and IMHO the document is focused too much on one implementation strategy, i.e., that of a stub logical interface not connected to any link, layered on top of physical interfaces, at the expense of describing a generic abstract model of a logical interface that can be implemented in many manners. In doing so, the document unnecessarily restrict the applicability of the logical interface concept and describes workarounds that seem overly complex and unnecessary. For example, the concept of virtual identifier seems to prevent doing inter technology handovers. o In access architectures, where the link-layer identifier is associated with a specific access technology, it will not be possible for the logical interface to adopt a virtual identifier and it use it across different access networks. In such networks, the logical interface must use the identifier of the respective sub-interface through which a packet is being transmitted. However, if more than one access technology domains that are part of the logical interface have such requirement, then the logical interface will not be able to support such configuration. It seems to me that much of the issues revolving around link layer identifiers, MTU, Neighbor Discovery, and Multicast, could be avoided if the document eliminated the current dependency on the implementation strategy being described in favor of a comprehensive logical interface support, where the logical interface is attached to a logical link which is terminated by a logical router. This logical router would in turn be attached to the physical interfaces themselves and perform adequate routing. Doing so, the IP layer on the host runs unmodified and uses the logical interface as any other interface. ND/ARP/DHCP etc. are executed together with the logical router at the end of the logical link, so is multicast. Dissimilar MTU of physical interfaces are hidden behind the logical router as well... Unlike the approach currently described in the document, I see only advantages and no drawbacks to what I am proposing here. Also note that this model is currently implemented and shipping on many mobile devices, where two flavors of the model coexist; one where the logical link is PPP, and another where it is Ethernet-like. --julien From sgundave@cisco.com Mon Apr 30 17:25:13 2012 Return-Path: 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 A517121E809F for ; Mon, 30 Apr 2012 17:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Vukxa6aTcgjq for ; Mon, 30 Apr 2012 17:25:12 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F16621E8037 for ; Mon, 30 Apr 2012 17:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2577; q=dns/txt; s=iport; t=1335831912; x=1337041512; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=K2eDY8fRzBAAxyH4ENHQhvwHzi7J3iYxU98wu/PdiwE=; b=XUsDxEtnnwwPSnVFoN3xc3t9RTIwuicyjWhpdLYdoxqOw5QBLnzwEf7d DVo4gEV3PTcbSIa22STc2QnZGw4118yHRxpTNhbaEtCw5os+4t198vKKc dRFQXNpvgf+JD61onBkutslk7tAtMe+7ZHVrx49v1f9Eg0nYu2m8gwu1Z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAB4sn0+rRDoH/2dsb2JhbABEr2ODAIEHggkBAQEDAQEBAQ8BJzQLBQsLRicwBhMih2YEDJoroAEEkCxjBIhkjRqOWYFpgwg X-IronPort-AV: E=Sophos;i="4.75,507,1330905600"; d="scan'208";a="42881785" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 01 May 2012 00:25:11 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q410PBn1011455; Tue, 1 May 2012 00:25:11 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Sri Gundavelli In-Reply-To: Date: Mon, 30 Apr 2012 17:25:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D7A23C8-0B20-4A95-AE17-7C6927E6E261@cisco.com> References: To: "" X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:25:13 -0000 On Apr 30, 2012, at 2:13 PM, = wrote: >=20 > A few questions that come to mind: >=20 > 1. Sec 6.2 discusses inter-technology handovers. What happens in the > scenario of a break-before-make handover? Interface 1 goes down and = there > is a brief interval before another interface (2) becomes active. How = does > the logical interface behave in such a scenario? Do you still maintain = the > existing connections? The LIF may not have any awareness of whether > another physical interface will be activated. >=20 [Sri]=20 1. The stated assumption for the LIF is about overlapping network = coverage; there is WLAN coverage and there is LTE coverage and in that = scenario how can we do a session handoff across these access technology = domains. This is clearly about about make-before-break. LIF has no = magic to anticipate handover scenarios. Applications will break, if the = interfaces that the LIF is abstracting are down. After an handover if = the L3 network to which the applications are bound continues to be = available, applications will survive, else they will break. > 2. Regarding path MTU, the I-D says that in the case where the MN is > attached simultaneously to multiple interfaces, the LIF will choose = the > smaller of the MTU values of the physical interfaces. However the I-D > also says that the LIF has awareness of forwarding packets on the > interface from which a packet was received. If that is the case, why = would > the LIF be configured with the lower value MTU? The LIF should be able = to > choose the appropriate MTU for sending a packet depending on the = interface > over which the packet is sent/received. >=20 [Sri] Keeping the lower of the MTU values across different interfaces = will ensure there is no MTU change notification to the ND stack after = each handover. It will keep a stable MTU value. > 3. The statement: "The logical interface adapts to the point-to-point = link > model." is not completely clear. What exactly is the LIF adapting to? >=20 [Sri] We have had this discussion in the past on this topic. LIF is = adapting to P2P link model. May be we can add more details. > 4. Sec 3.2 is unclear. Please elaborate on the requirements and > applicability. >=20 [Sri] Agreed. Will fix this Thanks for the review. Sri > -Raj=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Apr 30 17:25:28 2012 Return-Path: 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 93ED221E80DB for ; Mon, 30 Apr 2012 17:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 W2thcTMQhYdr for ; Mon, 30 Apr 2012 17:25:18 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2562C21E8037 for ; Mon, 30 Apr 2012 17:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=4215; q=dns/txt; s=iport; t=1335831917; x=1337041517; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GwJh0yXRXAM65gqO4g0ZxApedyurVywi2FEIkTg14Oc=; b=O+4zwulIpfKdYemybBII2OIQjiW+QRPX7Xq6Yuyy9pz6Sk7D1mQ2LDo+ jM5FPgjqxUpTBaSUDcoaU+DglOYbo7nwW3534nkYgI347kgcOIBHkq/Yr PlOSpuccXGrnrQFWrfae94d/D+eps6MbNBF4oGY3fL3zmOofNDOY84yKR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADYtn0+rRDoH/2dsb2JhbABEr2ODAIEHggkBAQEDAQEBAQ8BJzQLBQsLGC4nMAYTCRmHZgQMmi2gBJAsYwSIZI0ajlmBaYMI X-IronPort-AV: E=Sophos;i="4.75,507,1330905600"; d="scan'208";a="39769059" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 01 May 2012 00:25:15 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q410PBn2011455; Tue, 1 May 2012 00:25:14 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Sri Gundavelli In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716DF7B41@dfweml512-mbx.china.huawei.com> Date: Mon, 30 Apr 2012 17:25:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E27B87B-786B-473D-A28E-CD0E37231C7E@cisco.com> References: <20120429084048.15825.64421.idtracker@ietfa.amsl.com> <5963DDF1F751474D8DEEFDCDBEE43AE716DF7B41@dfweml512-mbx.china.huawei.com> To: Peter McCann X-Mailer: Apple Mail (2.1257) Cc: "netext@ietf.org" Subject: Re: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:25:29 -0000 Hi Pete, Thanks. Let me see how to best address the issue related to your = concern.=20 Regards Sri On Apr 30, 2012, at 1:51 PM, Peter McCann wrote: > I see the additional discussion of multiple provisioning domains in = Section 5.6, > but I am still not completely happy. The text seems to imply that all = physical > interfaces belonging to a single logical interface MUST belong to the = same > provisioning domain. While this might be true for some types of = handovers, > I think it is possible for a particular interface to be part of a = different > provisioning domain at other times. For example, I don't want my WiFi = hardware > to be always tied up with my 3G interface. There are times when I = want to=20 > use my WiFi interface to connect to a network other than my 3G = provider. >=20 > You say in another place that physical interfaces can be added/deleted = dynamically > from the logical interface, but how do you know when you should do = that? Can > you look at router advertisements or something and tell when you are = in the > same provisioning domain and when you are not? I think some more = discussion > on this topic is warranted. >=20 > -Pete >=20 > Basavaraj.Patil@nokia.com wrote: >>=20 >> Hello, >>=20 >> The authors have revised the I-D and addressed concerns that have = been >> previously raised. >> We (chairs) would like WG members to review the I-D and provide >> feedback via the mailing list. >>=20 >> Please make an effort and do a review of this I-D. >>=20 >> -Chairs >>=20 >> On 4/29/12 3:40 AM, "ext internet-drafts@ietf.org" >> wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Network-Based Mobility >>> Extensions Working Group of the IETF. >>>=20 >>> Title : Logical Interface Support for multi-mode IP = Hosts >>> Author(s) : Telemaco Melia >>> Sri Gundavelli >>> Filename : draft-ietf-netext-logical-interface-support- = 05.txt >>> Pages : 25 Date : 2012-04-29 >>>=20 >>> A Logical Interface is a software semantic internal to the host >>> operating system. This semantic is available in all popular >>> operating systems and is used in various protocol implementations. >>> The Logical Interface support is required on the mobile node >>> operating in a Proxy Mobile IPv6 domain, for leveraging various >>> network-based mobility management features such as inter-technology >>> handoffs, multihoming and flow mobility support. This document >>> explains the operational details of Logical Interface construct and >>> the specifics on how the link-layer implementations hide the = physical >>> interfaces from the IP stack and from the network nodes on the >>> attached access networks. Furthermore, this document identifies = the >>> applicability of this approach to various link-layer technologies = and >>> analyzes the issues around it when used in context with various >>> mobility management features. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical- >>> interface -su pport-05.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical- >>> interface- sup port-05.txt >>>=20 >>> The IETF datatracker page for this Internet-Draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface- >>> su ppo rt/ >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Mon Apr 30 17:25:34 2012 Return-Path: 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 EFE7D21E80DB for ; Mon, 30 Apr 2012 17:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ju5A4Gz9bB3R for ; Mon, 30 Apr 2012 17:25:29 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E567C21E80B0 for ; Mon, 30 Apr 2012 17:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5465; q=dns/txt; s=iport; t=1335831929; x=1337041529; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eOuWvv2WI5m45rI+ABprLXjwEEy0lRgun4l0l6TZFqw=; b=OsTtyBA2QZ3AJxQQ7JyT7BgoMtDGTbTnhkLcj34JKXYEm2aLrBqRiR+d LxSWKXpix6cJhTxgmwglJxWYxCinudNWPoTIKpNKHiJMv5/qSi8+NU578 4f57QLBpEcQkKghrtf+TxXOR6/CcKTfZH/vJPMSrk+Jou3qkxYn80iJDB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADYtn0+rRDoH/2dsb2JhbABEr2ODAIEHggkBAQEDAQEBAQ8BWwsFCwsYFRknMAYTIodmBAyaLaAABI1egk5jBIhkjRqOWYFpgwg X-IronPort-AV: E=Sophos;i="4.75,507,1330905600"; d="scan'208";a="40307032" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2012 00:25:19 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q410PBn3011455; Tue, 1 May 2012 00:25:19 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Sri Gundavelli In-Reply-To: Date: Mon, 30 Apr 2012 17:25:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <818438E2-DB5D-475F-9E5A-D1509FEB13FB@cisco.com> References: <20120429084048.15825.64421.idtracker@ietfa.amsl.com> To: Julien Laganier X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] Review request: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:25:34 -0000 Hi Julien. Thanks for the comments. Inline ... On Apr 30, 2012, at 4:29 PM, Julien Laganier wrote: > On Mon, Apr 30, 2012 at 12:32 PM, wrote: >>=20 >> Please make an effort and do a review of this I-D. >=20 > I have reviewed this document and IMHO the document is focused too > much on one implementation strategy, i.e., that of a stub logical > interface not connected to any link, layered on top of physical > interfaces, at the expense of describing a generic abstract model of a > logical interface that can be implemented in many manners. In doing > so, the document unnecessarily restrict the applicability of the > logical interface concept and describes workarounds that seem overly > complex and unnecessary. For example, the concept of virtual > identifier seems to prevent doing inter technology handovers. >=20 Not sure, if that was our goal, but if any part of the text is focussed = on a specific approach, we have to fix that. Logical interface is a = software construct with certain expected behavior with respect to its = interfacing with the physical link, ND traffic handling, and with = respect to how the messages/events are forwarded up the stack. Clearly = this is a requirement spec with some minimal guidance on how to deal = with specific issues. The focus was mainly on: - The concept of a Logical Interface and the purpose - properties of the Logical interface, its related to the physical = interfaces - How does logical interface deal with link specific ND messages, how = RA's are seen, how RS is sent. L2 identifiers ... - Presents only the details/issues that the implementations have to be = aware off. As I see it, if I'm implementing a logical interface, I need to know = these details. Now, there can be multiple ways to implement and meet = these requirements. No part of the spec is using 2119 language, or = suggesting how to implement it. Its some general guidance. > o In access architectures, where the link-layer identifier is > associated with a specific access technology, it will not be > possible for the logical interface to adopt a virtual identifier > and it use it across different access networks. In such = networks, > the logical interface must use the identifier of the respective > sub-interface through which a packet is being transmitted. > However, if more than one access technology domains that are part > of the logical interface have such requirement, then the logical > interface will not be able to support such configuration. >=20 > It seems to me that much of the issues revolving around link layer > identifiers, MTU, Neighbor Discovery, and Multicast, could be avoided > if the document eliminated the current dependency on the > implementation strategy being described in favor of a comprehensive > logical interface support, where the logical interface is attached to > a logical link which is terminated by a logical router. This logical > router would in turn be attached to the physical interfaces themselves > and perform adequate routing. >=20 The above text is about a specific issue related to choice of interface = identifier selection. If WiMAX access is making certain assumption about = the interface identifier, a given implementation needs to be sensitive = to that aspect. So, we are only reflecting the issues with the interface = identifier selection and the considerations. So, I'm not sure, if the = above is about a specific implementation. The spec can be silent about = this, but implementations will have no clue. At the end of the day, this = is an informational spec, you and me/WG having worked on such things we = have some understanding about the issues. But, some developer may not be = aware of these considerations.=20 > This logical > router would in turn be attached to the physical interfaces themselves > and perform adequate routing. > Doing so, the IP layer on the host runs unmodified and uses the > logical interface as any other interface. ND/ARP/DHCP etc. are > executed together with the logical router at the end of the logical > link, so is multicast. Dissimilar MTU of physical interfaces are > hidden behind the logical router as well=85 >=20 One can surely make this a logical router ( I don't know how this works = ..), still taking into account the considerations listed in the = document. Not sure, what part of the spec is preventing any specific = implementation, still conforming to the logical interface requirements. > Unlike the approach currently described in the document, I see only > advantages and no drawbacks to what I am proposing here. >=20 > Also note that this model is currently implemented and shipping on > many mobile devices, where two flavors of the model coexist; one where > the logical link is PPP, and another where it is Ethernet-like. >=20 I agree with that. But, you also know, in the absence of some guidance = how different implementations have violated some basics and the current = situation with the 3G drivers. But, I again, we are not interested in = reflecting any specific implementation, the goal is to provide = requirements. Sri > --julien > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Apr 30 20:06:18 2012 Return-Path: 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 198CC21F86C4 for ; Mon, 30 Apr 2012 20:06:18 -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 rTqt7P2LDgO9 for ; Mon, 30 Apr 2012 20:06:16 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1394521F86B4 for ; Mon, 30 Apr 2012 20:06:15 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4136797021414; Tue, 1 May 2012 06:06:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 06:06:07 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Tue, 1 May 2012 05:06:06 +0200 From: To: Thread-Topic: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt Thread-Index: AQHNJxYMMu/A+bLcNEmdVxwqAA1fFpaz8gqA///ZIQA= Date: Tue, 1 May 2012 03:06:06 +0000 Message-ID: In-Reply-To: <9D7A23C8-0B20-4A95-AE17-7C6927E6E261@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 x-originating-ip: [96.226.49.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2012 03:06:07.0398 (UTC) FILETIME=[5A40F460:01CD2747] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 03:06:18 -0000 Inline: On 4/30/12 7:25 PM, "ext Sri Gundavelli" wrote: > >On Apr 30, 2012, at 2:13 PM, > wrote: > >>=20 >> A few questions that come to mind: >>=20 >> 1. Sec 6.2 discusses inter-technology handovers. What happens in the >> scenario of a break-before-make handover? Interface 1 goes down and >>there >> is a brief interval before another interface (2) becomes active. How >>does >> the logical interface behave in such a scenario? Do you still maintain >>the >> existing connections? The LIF may not have any awareness of whether >> another physical interface will be activated. >>=20 >[Sri]=20 >1. The stated assumption for the LIF is about overlapping network >coverage; there is WLAN coverage and there is LTE coverage and in that >scenario how can we do a session handoff across these access technology >domains. This is clearly about about make-before-break. LIF has no magic >to anticipate handover scenarios. Applications will break, if the >interfaces that the LIF is abstracting are down. After an handover if the >L3 network to which the applications are bound continues to be available, >applications will survive, else they will break. Then you should make this clear in the I-D that a logical interface will support inter-technology handovers only in the case of make-before-break scenarios.=20 > > >> 2. Regarding path MTU, the I-D says that in the case where the MN is >> attached simultaneously to multiple interfaces, the LIF will choose the >> smaller of the MTU values of the physical interfaces. However the I-D >> also says that the LIF has awareness of forwarding packets on the >> interface from which a packet was received. If that is the case, why >>would >> the LIF be configured with the lower value MTU? The LIF should be able >>to >> choose the appropriate MTU for sending a packet depending on the >>interface >> over which the packet is sent/received. >>=20 > >[Sri] Keeping the lower of the MTU values across different interfaces >will ensure there is no MTU change notification to the ND stack after >each handover. It will keep a stable MTU value. But it comes at the cost of sending packets on the interface in a suboptimal manner. As a result the bandwidth of the air-interface is (may be) wasted. Since the LI knows which of the interfaces to send the packets on, why does it need to adapt to the lower value MTU? I do not believe it is necessary. > > > >> 3. The statement: "The logical interface adapts to the point-to-point >>link >> model." is not completely clear. What exactly is the LIF adapting to? >>=20 > >[Sri] We have had this discussion in the past on this topic. LIF is >adapting to P2P link model. May be we can add more details. I am still at a loss to understand what you mean when you say "LIF is adapting to P2P link model". What exactly is happening at the LIF in terms of behavior? -Raj > > > >> 4. Sec 3.2 is unclear. Please elaborate on the requirements and >> applicability. >>=20 > >[Sri] Agreed. Will fix this > >Thanks for the review. > >Sri > > > >> -Raj=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From sgundave@cisco.com Mon Apr 30 20:45:55 2012 Return-Path: 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 4B65021E80CA for ; Mon, 30 Apr 2012 20:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 itSejsX6OLFs for ; Mon, 30 Apr 2012 20:45:54 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1D721E809A for ; Mon, 30 Apr 2012 20:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3979; q=dns/txt; s=iport; t=1335843954; x=1337053554; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=r8eq2i5SH8le7eiAVcSX9Dt5+RI7YW4FSeewwOLjEDs=; b=g+7yS1DLgUl5+/1w4tAqbceRy+bTs8y9dbfGBJ/P1z04d8+UodTMUxJG Ru+eagF2iH79BFm6lrmUH0WRo1h2ovLhG5g7hUMXLQkMZmrIaJvwLdOim wj/7PyD3/yFTqqkAnzFl6uBy5qV2ekmQ/KMEadN6V653CLJDtISwaiiiY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAClcn0+rRDoH/2dsb2JhbABEr2eDAIEHggkBAQEDARIBZgULCxguVwYTIodmBJoqoAGQImMEiGSNGo5ZgWmDCA X-IronPort-AV: E=Sophos;i="4.75,508,1330905600"; d="scan'208";a="39790108" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 01 May 2012 03:45:54 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q413jst1013621; Tue, 1 May 2012 03:45:54 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Sri Gundavelli In-Reply-To: Date: Mon, 30 Apr 2012 20:45:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "" X-Mailer: Apple Mail (2.1257) Cc: netext@ietf.org Subject: Re: [netext] Questions on: draft-ietf-netext-logical-interface-support-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 03:45:55 -0000 inline =85 On Apr 30, 2012, at 8:06 PM, = wrote: > Inline: >=20 > On 4/30/12 7:25 PM, "ext Sri Gundavelli" wrote: >=20 >>=20 >> On Apr 30, 2012, at 2:13 PM, >> wrote: >>=20 >>>=20 >>> A few questions that come to mind: >>>=20 >>> 1. Sec 6.2 discusses inter-technology handovers. What happens in the >>> scenario of a break-before-make handover? Interface 1 goes down and >>> there >>> is a brief interval before another interface (2) becomes active. How >>> does >>> the logical interface behave in such a scenario? Do you still = maintain >>> the >>> existing connections? The LIF may not have any awareness of whether >>> another physical interface will be activated. >>>=20 >> [Sri]=20 >> 1. The stated assumption for the LIF is about overlapping network >> coverage; there is WLAN coverage and there is LTE coverage and in = that >> scenario how can we do a session handoff across these access = technology >> domains. This is clearly about about make-before-break. LIF has no = magic >> to anticipate handover scenarios. Applications will break, if the >> interfaces that the LIF is abstracting are down. After an handover if = the >> L3 network to which the applications are bound continues to be = available, >> applications will survive, else they will break. >=20 > Then you should make this clear in the I-D that a logical interface = will > support inter-technology handovers only in the case of = make-before-break > scenarios.=20 >=20 Sure >>=20 >>=20 >>> 2. Regarding path MTU, the I-D says that in the case where the MN is >>> attached simultaneously to multiple interfaces, the LIF will choose = the >>> smaller of the MTU values of the physical interfaces. However the = I-D >>> also says that the LIF has awareness of forwarding packets on the >>> interface from which a packet was received. If that is the case, why >>> would >>> the LIF be configured with the lower value MTU? The LIF should be = able >>> to >>> choose the appropriate MTU for sending a packet depending on the >>> interface >>> over which the packet is sent/received. >>>=20 >>=20 >> [Sri] Keeping the lower of the MTU values across different interfaces >> will ensure there is no MTU change notification to the ND stack after >> each handover. It will keep a stable MTU value. >=20 > But it comes at the cost of sending packets on the interface in a > suboptimal manner. As a result the bandwidth of the air-interface is = (may > be) wasted. Since the LI knows which of the interfaces to send the = packets > on, why does it need to adapt to the lower value MTU? I do not believe = it > is necessary. The other aspect is constant MTU change at each handoff. So, we can = leave both the considerations and let implementations decide. >>=20 >>=20 >>> 3. The statement: "The logical interface adapts to the = point-to-point >>> link >>> model." is not completely clear. What exactly is the LIF adapting = to? >>>=20 >>=20 >> [Sri] We have had this discussion in the past on this topic. LIF is >> adapting to P2P link model. May be we can add more details. >=20 > I am still at a loss to understand what you mean when you say "LIF is > adapting to P2P link model". What exactly is happening at the LIF in = terms > of behavior? >=20 Every interface that is exposed to the ND stack is reflecting the = interface type, shared/p2p. There is even a socket API to get this = property and its used by the application/ND stack for different = purposes, Now, the question is about LIF, what is the tag that exposed = to the upper layer. The LIF operation has no bearing on the type and = given that we have pre-established assumption on the link model, we = rather expect the LIF be of another P2P link type. That's all to it. Sri
Re: [netext] New Version Notification for draft-liebsch-netext-pmi= p6-qos-01.txt
Folks:

Please comment on this draft. Lot of efforts went in to this from all the A= uthors, please review and comment.

http://www.ietf.org/id/draft-liebsch-ne= text-pmip6-qos-01.txt



Regards
Sri



On 3/13/12 8:40 AM, "Marco Liebsch" <M= arco.Liebsch@neclab.eu> wrote:

Please = find an update of our draft about a QoS option for PMIP6 on the IETF reposit= ory, which
addresses comments from last meeting. The current version includes more det= ails about the
proposed operation and QoS attributes.
 
Marco
 
Filename:            = ;draft-liebsch-netext-pmip6-qos
Revision:            = ;  01
Title:            &n= bsp;         Quality of Service= Option for Proxy Mobile IPv6
Creation date:   2012-03-12
WG ID:            &n= bsp;     Individual Submission
Number of pages: 32
Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt
 
Abstract:
   This specification defines a new mobility option that can= be used by
   the mobility entities in the Proxy Mobile IPv6 domain to = exchange
   Quality of Service parameters associated with a subscribe= r&#39;s IP
   flows.  Using the QoS option, the local mobility anc= hor and the
   mobile access gateway can exchange available QoS attribut= es and
   associated values.  This enables QoS policing and la= beling of packets
   to enforce QoS differentiation on the path between the lo= cal mobility
   anchor and the mobile access gateway.  Furthermore, = making QoS
   parameters available on the MAG enables mapping these par= ameters to
   QoS rules being specific to the access technology which o= perates
   below the mobile access gateway.  After such mapping= , QoS rules can
   be enforced on the access technology components, such as = an IEEE
   802.11e Wireless LAN controller.
 
 

_______________________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org/mai= lman/listinfo/netext