From xueli@huawei.com Thu May 3 02:18:18 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7931721F85D3 for ; Thu, 3 May 2012 02:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7YmvmxVtTG+M for ; Thu, 3 May 2012 02:18:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE021F854C for ; Thu, 3 May 2012 02:18:16 -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 AFU21504; Thu, 03 May 2012 05:18:16 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 3 May 2012 02:16:37 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 3 May 2012 02:16:42 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.58]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Thu, 3 May 2012 17:16:37 +0800 From: Xueli To: "fmc@ietf.org" Thread-Topic: Some comments to the community wifi draft Thread-Index: Ac0pDW6BjvrQ8fjDSK2j1wFgTHajQg== Date: Thu, 3 May 2012 09:16:36 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B42C42C9BA@szxeml528-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ACrx Ap05 CG8a DAZw Dvch FSR8 FhRi Fzu7 F7Zn GC+u GWJ4 Gz/E HH2x IkrE JyzZ K9yp; 1; ZgBtAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {87271ED0-0A63-450B-96F4-75BFF650324E}; eAB1AGUAbABpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 03 May 2012 09:16:32 GMT; UwBvAG0AZQAgAGMAbwBtAG0AZQBuAHQAcwAgAHQAbwAgAHQAaABlACAAYwBvAG0AbQB1AG4AaQB0AHkAIAB3AGkAZgBpACAAZAByAGEAZgB0AA== x-cr-puzzleid: {87271ED0-0A63-450B-96F4-75BFF650324E} x-originating-ip: [10.108.4.71] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B42C42C9BAszxeml528mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [fmc] Some comments to the community wifi draft X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 09:18:18 -0000 --_000_01FE63842C181246BBE4CF183BD159B42C42C9BAszxeml528mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, I have went through the new draft( http://tools.ietf.org/rfcdiff?url2=3Ddra= ft-gundavelli-v6ops-community-wifi-svcs-04.txt). I have several comments on this draft. Please see as follows. 1 Section 4.1 IPv6 addressing Model for SP WiFi architecture. I agree 3GPP architecture supports unique-prefix model for the mobile node'= s PDN connections. In the context of WiFi, I am not sure this same requirement must be satisfied. First, when a UE is connecting to the Wifi, there are two kinds service fro= m UE, internet (local breakout) or operators' service / internet service (need go through the EPC core network). For the EPC point of view, the UE obtains an IP address from the EPC networ= k for the operator's service, which is unique-prefix model. For the wifi point of view, the UE obtains a local IP address for operator'= s or internet service (need go through the EPC core network) So we can see two kinds IP addresses will be assigned to UE. When a UE is connecting to the LTE, unique-prefix model is used. If the mobile node performs handover from macro network to the WLAN network= for internet service, I am not sure the unique prefix model should be adopted, except special sce= narios, such as integration or interworking. But you said, "Even in deployment models where such handovers are no envisi= oned, such as an WLAN access aggregation architecture with no mobile packet core = integration, there are sufficient reasons for adopting the Unique Prefix model.". Could = you clarify this? 2 Section 4.6 Multiple WLAN SSID support I am wondering whether it is the requirement section of Community WiFi. IMH= O, community wifi is kind of service or service requirements. Multiple WLAN SSID supported in residential wifi hotspots seems like a solu= tion instead of the requirements. Even more, this section is the implementation issue. Do you mind to clarify the real requirements of community wifi? Then we can think about the IETF solutions, that would be better. 3 Section 4.9 CPE identity and authorization What about to merge the authorization elements to section 4.1, which is aut= hentication and authorization related. 4 Section 4.15 This section seems like the issues introduced by multiple SSID deployment. = My confusion is mentioned in the second comment. I suggest the real requirements of community wifi should be clarified at fi= rst. 5 some suggestion on these requirements , such as section 4.5, 4.9, etc, me= ntioned in the draft. These are SDO areas, and we should concentrate on these requirements to ide= ntify what IETF can do and state requirements on IETF work. What about your opinion? BR Li --_000_01FE63842C181246BBE4CF183BD159B42C42C9BAszxeml528mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

I have went through the new dra= ft( http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops-community-wifi-= svcs-04.txt).

I have several comments on this= draft.

Please see as follows.

 

1 Section 4.1 IPv6 addressing M= odel for SP WiFi architecture.

 

I agree 3GPP architecture suppo= rts unique-prefix model for the mobile node’s PDN connections. In the= context of WiFi,

I am not sure this same require= ment must be satisfied.

First, when a UE is connecting = to the Wifi, there are two kinds service from UE, internet (local breakout)= or operators’ service

/ internet service (need go thr= ough the EPC core network).

For the EPC point of view, the = UE obtains an IP address from the EPC network for the operator’s serv= ice, which is unique-prefix model.

For the wifi point of view, the= UE obtains a local IP address for operator’s or internet service (ne= ed go through the EPC core network)

So we can see two kinds IP addr= esses will be assigned to UE.

 

When a UE is connecting to the = LTE, unique-prefix model is used.

 

If the mobile node performs han= dover from macro network to the WLAN network for internet service,

I am not sure the unique prefix= model should be adopted, except special scenarios, such as integration or = interworking.

But you said, “Even in deployment models where such handovers are no envisioned,

such as = an WLAN access aggregation architecture with no mobile packet core integration,

there ar= e sufficient reasons for adopting the Unique Prefix model.”. Could you = clarify this?

&nb= sp;

2 Sectio= n 4.6 Multiple WLAN SSID support

I am won= dering whether it is the requirement section of Community WiFi. IMHO, commu= nity wifi is kind of service or service requirements.

Multiple= WLAN SSID supported in residential wifi hotspots seems like a solution ins= tead of the requirements.

Even mor= e, this section is the implementation issue.

Do you m= ind to clarify the real requirements of community wifi?

Then we = can think about the IETF solutions, that would be better.

&nb= sp;

3 Sectio= n 4.9 CPE identity and authorization

What abo= ut to merge the authorization elements to section 4.1, which is authenticat= ion and authorization related.

&nb= sp;

4 Sectio= n 4.15

&nb= sp;

This sec= tion seems like the issues introduced by multiple SSID deployment. My confu= sion is mentioned in the second comment.

I sugges= t the real requirements of community wifi should be clarified at first.

&nb= sp;

5 some s= uggestion on these requirements , such as section 4.5, 4.9, etc, mentioned = in the draft.

These ar= e SDO areas, and we should concentrate on these requirements to identify wh= at IETF can do and state requirements on IETF work.

What abo= ut your opinion?

&nb= sp;

BR<= /o:p>

Li

 

 

 

--_000_01FE63842C181246BBE4CF183BD159B42C42C9BAszxeml528mbschi_-- From sgundave@cisco.com Thu May 3 13:52:39 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7222421F8691 for ; Thu, 3 May 2012 13:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.592 X-Spam-Level: X-Spam-Status: No, score=-10.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3TSgcuU7CmRT for ; Thu, 3 May 2012 13:52:38 -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 57E9921F8592 for ; Thu, 3 May 2012 13:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=29486; q=dns/txt; s=iport; t=1336078358; x=1337287958; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=120rhA9XaiPj8U6gEBDqoC7LgAk82TUHO93kyd69Jjk=; b=c+3YVQo+6Y8VnrJNXT8aqj9qMvUQ3GuwXDSeTpj4A4JN0c1MgcRHXCa9 aQK/awOe60fuAH4JY9KPLbFe02tA8Whzi+KRNvlGl/+B6jNFApBQGOR7n sON+oGX60g7ALA1mE8T9tRk9i/3b1BrPUeWU+WOkepGu0tCdmjW66oH4c 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAC3vok+rRDoJ/2dsb2JhbAA7AQmCRqZtAYlIgQeCCQEBAQMBAQEBDwFbCwULCxImAQ0nIg4GExQHB4VvgXcEDJpIoCOKfAGFKGMEiGSNGoERjUiBaYMIgTw X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208,217";a="43396604" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 May 2012 20:52:38 +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 q43Kqbb4009485; Thu, 3 May 2012 20:52:37 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_8788A153-5370-4F83-9C34-BDC76B7101EA" From: Sri Gundavelli In-Reply-To: <01FE63842C181246BBE4CF183BD159B42C42C9BA@szxeml528-mbs.china.huawei.com> Date: Thu, 3 May 2012 13:52:37 -0700 Message-Id: References: <01FE63842C181246BBE4CF183BD159B42C42C9BA@szxeml528-mbs.china.huawei.com> To: Xueli X-Mailer: Apple Mail (2.1257) Cc: "fmc@ietf.org" Subject: Re: [fmc] Some comments to the community wifi draft X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 20:52:39 -0000 --Apple-Mail=_8788A153-5370-4F83-9C34-BDC76B7101EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 HI Li, Thanks for the review. inline =85 On May 3, 2012, at 2:16 AM, Xueli wrote: > Hi, all, > I have went through the new draft( = http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops-community-wifi= -svcs-04.txt). > I have several comments on this draft. > Please see as follows. > =20 > 1 Section 4.1 IPv6 addressing Model for SP WiFi architecture. > =20 > I agree 3GPP architecture supports unique-prefix model for the mobile = node=92s PDN connections. In the context of WiFi, > I am not sure this same requirement must be satisfied. It depends. There are very good reasons why IETF made a recommendation = to 3GPP to support Per-MN prefix model. Clearly there are advantages = that stand out. For SP WIFI architectures, the considerations are no = different. We also need to think from the perspective of the handover = from macros access to trusted WLAN access, the choice of different = addressing will make handovers difficult. > First, when a UE is connecting to the Wifi, there are two kinds = service from UE, internet (local breakout) or operators=92 service > / internet service (need go through the EPC core network). > For the EPC point of view, the UE obtains an IP address from the EPC = network for the operator=92s service, which is unique-prefix model. > For the wifi point of view, the UE obtains a local IP address for = operator=92s or internet service (need go through the EPC core network) > So we can see two kinds IP addresses will be assigned to UE. > =20 > When a UE is connecting to the LTE, unique-prefix model is used. > =20 > If the mobile node performs handover from macro network to the WLAN = network for internet service, > I am not sure the unique prefix model should be adopted, except = special scenarios, such as integration or interworking. > But you said, =93Even in deployment models where such handovers are no = envisioned, > such as an WLAN access aggregation architecture with no mobile packet = core integration, > there are sufficient reasons for adopting the Unique Prefix model.=94. = Could you clarify this? > =20 That is one approach, but lets look at some other considerations. The = mobile node is using Stateless Autoconf for address configuration and = now the operator asks the vendor to do per-user accounting. How does = that work ? The gateway will start tracking all the IPv6 address that = the mobile node generates ? If it generates like a dozen IPv6 addresses = for ephemeral lifetime, will the gateway track all these addresses ? = Will it report all these addresses in Accounting-Start/AAA ? How about = LI ? How about we assign a single prefix and track that one prefix ? = What is a better approach and what is our recommendation ? > 2 Section 4.6 Multiple WLAN SSID support > I am wondering whether it is the requirement section of Community = WiFi. IMHO, community wifi is kind of service or service requirements. > Multiple WLAN SSID supported in residential wifi hotspots seems like a = solution instead of the requirements. > Even more, this section is the implementation issue. > Do you mind to clarify the real requirements of community wifi? > Then we can think about the IETF solutions, that would be better. > =20 This is a requirement. All most all WLAN networks have this concept of = guest user/guest user service differentiation. The aspect of SSID based = separation is one approach. Sure, this can be generalized with the use = of HotSpot2.0. But, the key point is service differentiation. > 3 Section 4.9 CPE identity and authorization > What about to merge the authorization elements to section 4.1, which = is authentication and authorization related. > =20 There is this aspect of CPE identity, authorization and then there is = the aspict of service authorization to users. There are good reasons to = separate them. As we bring some more analysis, this part will be clear. = If there is need, it can be collapsed. > 4 Section 4.15 > =20 > This section seems like the issues introduced by multiple SSID = deployment. My confusion is mentioned in the second comment. > I suggest the real requirements of community wifi should be clarified = at first. > =20 These are practical issues related to WiFi deployments in SP context. = This translates into some specific requirements on the protocol layers. = Lets discuss further. > 5 some suggestion on these requirements , such as section 4.5, 4.9, = etc, mentioned in the draft. > These are SDO areas, and we should concentrate on these requirements = to identify what IETF can do and state requirements on IETF work. > What about your opinion? > =20 Yes. At the end we need to see how best the tools we have can be used = for supporting these architectures. Thanks for your comments. Regards Sri > BR > Li > =20 > =20 > =20 > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc --Apple-Mail=_8788A153-5370-4F83-9C34-BDC76B7101EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 HI Li,

Thanks for the review. = inline = =85







First, when a = UE is connecting to the Wifi, there are two kinds service from UE, = internet (local breakout) or operators=92 = service
/ internet service (need go through = the EPC core network).
For the EPC point of view, the UE = obtains an IP address from the EPC network for the operator=92s service, = which is unique-prefix model.
For the wifi = point of view, the UE obtains a local IP address for operator=92s or = internet service (need go through the EPC core = network)
So we can see two kinds IP addresses = will be assigned to = UE.
 
When a UE is = connecting to the LTE, unique-prefix model is = used.
 
If the mobile = node performs handover from macro network to the WLAN network for = internet service,
I am not sure the unique prefix model = should be adopted, except special scenarios, such as integration or = interworking.
But you said, =93Even in deployment models where such handovers are = no envisioned,
such as an WLAN access aggregation architecture with = no mobile= packet core integration,
there are sufficient reasons for adopting the Unique Prefix model.=94. Could you clarify = this?
 


That is one approach, = but lets look at some other considerations. The mobile node is using = Stateless Autoconf for address configuration and now the operator asks = the vendor to do per-user accounting. How does that work ? The gateway = will start tracking all the IPv6 address that the mobile node generates = ? If it generates like a dozen IPv6 addresses for ephemeral lifetime, = will the gateway track all these addresses ? Will it report all these = addresses in Accounting-Start/AAA ? How about LI ? How about we assign a = single prefix and track that one prefix ? What is a better approach and = what is our recommendation = ?




2 Section 4.6 = Multiple WLAN SSID support
I am wondering whether it is the requirement section of = Community WiFi. IMHO, community wifi is kind of service or service = requirements.
Multiple WLAN = SSID supported in residential wifi hotspots seems like a solution = instead of the requirements.
Even more, this section is the implementation = issue.
Do you mind to = clarify the real requirements of community = wifi?
Then we can = think about the IETF solutions, that would be = better.
 


This is a requirement. All = most all WLAN networks have this concept of guest user/guest user = service differentiation. The aspect of SSID based separation is one = approach. Sure, this can be generalized with the use of HotSpot2.0. But, = the key point is service = differentiation.



3 Section 4.9 = CPE identity and authorization
What about to merge the authorization elements to section = 4.1, which is authentication and authorization = related.
 

There is this aspect of CPE identity, = authorization and then there is the aspict of service authorization to = users. There are good reasons to separate them. As we bring some more = analysis, this part will be clear. If there is need, it can be = collapsed.



4 Section = 4.15
 
This section seems like the issues introduced by multiple = SSID deployment. My confusion is mentioned in the second = comment.
I suggest the = real requirements of community wifi should be clarified at = first.
 

These are practical issues related to WiFi = deployments in SP context. This translates into some specific = requirements on the protocol layers. Lets discuss = further.



5 some = suggestion on these requirements , such as section 4.5, 4.9, etc, = mentioned in the draft.
These are SDO areas, and we should concentrate on these = requirements to identify what IETF can do and state requirements on IETF = work.
What about = your opinion?
 

Yes. At the end we need to see how best = the tools we have can be used for supporting these = architectures.

Thanks for your = comments.

Regards
Sri




BR
Li
 
_______________________= ________________________
fmc mailing list
fmc@ietf.org
 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:29:06 -0000 --_000_05C81A773E48DD49B181B04BA21A342A27978B02ACHE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sri, all, in general I think that the updated draft http://tools.ietf.org/rfcdiff?url= 2=3Ddraft-gundavelli-v6ops-community-wifi-svcs-04.txt addresses several FMC= issues which might be included in the planned FMC problem statement or req= uirements draft. I agree with Li that requirements in different sections on= authentication might be grouped together. BTW strictly speaking when you say below The aspect of SSID based separation is one approach. doesn't this imply that the requirement is to enable service differentiatio= n, and multiple SSIDs per AP is one potential solution? But as mentioned the draft is a collection of identified issues and provide= s a good basis for FMC work together with others such as http://tools.ietf.= org/html/draft-ietf-intarea-nat-reveal-analysis-01, http://tools.ietf.org/= html/draft-liebsch-netext-pmip6-qos-01, and http://tools.ietf.org/id/draft-= xue-intarea-fmc-ps-02.txt. What do you think of an attempt to merge aspects addressed within them? Another minor remark: I may have misunderstood the introductory remarks say= ing that a mobile operator will see WiFi as "the basis for offering new wir= eless broadband services" ... I'd rather think it is seen as an add-on/com= pletion of the cellular coverage for dedicated services. Beside that only r= egarding smartphones and tablets almost every new mobile device is now equi= pped with IEEE 802.11-based wireless interface - there are still many new (= low-cost) devices without. And I think, at least in Europe for the time bei= ng most of the devices are pre-configured with a policy to prefer cellular = packet data access to WiFi. Best regards Dirk ________________________________ Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von Sri = Gundavelli Gesendet: Donnerstag, 3. Mai 2012 22:53 An: Xueli Cc: fmc@ietf.org Betreff: Re: [fmc] Some comments to the community wifi draft HI Li, Thanks for the review. inline ... On May 3, 2012, at 2:16 AM, Xueli wrote: Hi, all, I have went through the new draft( http://tools.ietf.org/rfcdiff?url2=3Ddra= ft-gundavelli-v6ops-community-wifi-svcs-04.txt). I have several comments on this draft. Please see as follows. 1 Section 4.1 IPv6 addressing Model for SP WiFi architecture. I agree 3GPP architecture supports unique-prefix model for the mobile node'= s PDN connections. In the context of WiFi, I am not sure this same requirement must be satisfied. It depends. There are very good reasons why IETF made a recommendation to 3= GPP to support Per-MN prefix model. Clearly there are advantages that stand= out. For SP WIFI architectures, the considerations are no different. We al= so need to think from the perspective of the handover from macros access to= trusted WLAN access, the choice of different addressing will make handover= s difficult. First, when a UE is connecting to the Wifi, there are two kinds service fro= m UE, internet (local breakout) or operators' service / internet service (need go through the EPC core network). For the EPC point of view, the UE obtains an IP address from the EPC networ= k for the operator's service, which is unique-prefix model. For the wifi point of view, the UE obtains a local IP address for operator'= s or internet service (need go through the EPC core network) So we can see two kinds IP addresses will be assigned to UE. When a UE is connecting to the LTE, unique-prefix model is used. If the mobile node performs handover from macro network to the WLAN network= for internet service, I am not sure the unique prefix model should be adopted, except special sce= narios, such as integration or interworking. But you said, "Even in deployment models where such handovers are no envisi= oned, such as an WLAN access aggregation architecture with no mobile packet core = integration, there are sufficient reasons for adopting the Unique Prefix model.". Could = you clarify this? That is one approach, but lets look at some other considerations. The mobil= e node is using Stateless Autoconf for address configuration and now the op= erator asks the vendor to do per-user accounting. How does that work ? The = gateway will start tracking all the IPv6 address that the mobile node gener= ates ? If it generates like a dozen IPv6 addresses for ephemeral lifetime, = will the gateway track all these addresses ? Will it report all these addre= sses in Accounting-Start/AAA ? How about LI ? How about we assign a single = prefix and track that one prefix ? What is a better approach and what is ou= r recommendation ? 2 Section 4.6 Multiple WLAN SSID support I am wondering whether it is the requirement section of Community WiFi. IMH= O, community wifi is kind of service or service requirements. Multiple WLAN SSID supported in residential wifi hotspots seems like a solu= tion instead of the requirements. Even more, this section is the implementation issue. Do you mind to clarify the real requirements of community wifi? Then we can think about the IETF solutions, that would be better. This is a requirement. All most all WLAN networks have this concept of gues= t user/guest user service differentiation. The aspect of SSID based separat= ion is one approach. Sure, this can be generalized with the use of HotSpot2= .0. But, the key point is service differentiation. 3 Section 4.9 CPE identity and authorization What about to merge the authorization elements to section 4.1, which is aut= hentication and authorization related. There is this aspect of CPE identity, authorization and then there is the a= spict of service authorization to users. There are good reasons to separate= them. As we bring some more analysis, this part will be clear. If there is= need, it can be collapsed. 4 Section 4.15 This section seems like the issues introduced by multiple SSID deployment. = My confusion is mentioned in the second comment. I suggest the real requirements of community wifi should be clarified at fi= rst. These are practical issues related to WiFi deployments in SP context. This = translates into some specific requirements on the protocol layers. Lets dis= cuss further. 5 some suggestion on these requirements , such as section 4.5, 4.9, etc, me= ntioned in the draft. These are SDO areas, and we should concentrate on these requirements to ide= ntify what IETF can do and state requirements on IETF work. What about your opinion? Yes. At the end we need to see how best the tools we have can be used for s= upporting these architectures. Thanks for your comments. Regards Sri BR Li _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc --_000_05C81A773E48DD49B181B04BA21A342A27978B02ACHE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3D"x-msg://5051/">
Dear Sri, all,
in general I think that the updated=20 draft http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops-co= mmunity-wifi-svcs-04.txt addresses several FMC issues which might be included in the planned FMC problem statement or requirements = draft.=20 I agree with Li that requirements in different sections on authentication m= ight=20 be grouped together.
BTW strict= ly=20 speaking when you  say below
The aspect of SSID based separation is one=20 approach.
doesn't this=20 imply that the requirement is to enable service differentiation, and=20 multiple SSIDs per AP is one potential solution?<= /DIV>
But as mentione= d the=20 draft is a collection of identified issues and provides a good basis for FM= C=20 work together with others such as http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis= -01,  http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01<= /FONT>,=20 and http://to= ols.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt.=20
 
What do you thi= nk of an=20 attempt to merge aspects addressed within them?
=  
= Another minor remark: = I may=20 have misunderstood the= =20 introductory remarks saying that a mobile operator will see WiFi as "the ba= sis=20 for offering new wireless broadband services"  ... I'd rather think it is seen as=20 an add-on/completion of the cellular coverage for dedicated=20 services. Beside that only regarding smartphones and tablets almost = every=20 new mobile device is now equipped with IEEE 802.11-based wireless=20 interface - there are still many=20 new (low-cost) devices without. And I think, at least in Europe for the time = being=20 most of the devices are pre-configured with a policy to prefer cellular packet data access to WiFi.
 
= Best=20 regards
Di= rk=20
 
Von: fmc-bounces@ietf.org=20 [mailto:fmc-bounces@ietf.org] Im Auftrag von Sri=20 Gundavelli
Gesendet: Donnerstag, 3. Mai 2012 22:53
An:= =20 Xueli
Cc: fmc@ietf.org
Betreff: Re: [fmc] Some comments= to=20 the community wifi draft

HI Li,

Thanks for the review. inline …




On May 3, 2012, at 2:16 AM, Xueli wrote:
Hi, all,
I have went through the new draft( http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavell= i-v6ops-community-wifi-svcs-04.txt).
I have several comments on this draft. Please see as follows.
1 Section 4.1 IPv6 addressing Model for SP WiFi=20 architecture.
I agree 3GPP architecture supports unique-prefix model for t= he=20 mobile node’s PDN connections. In the context of WiFi,
I am not sure this same requirement must be=20 satisfied.


It depends. There are very good reasons why IETF made a recommendation= to=20 3GPP to support Per-MN prefix model. Clearly there are advantages that stan= d=20 out. For SP WIFI architectures, the considerations are no different. We als= o=20 need to think from the perspective of the handover from macros access to tr= usted=20 WLAN access, the choice of different addressing will make handovers=20 difficult.



First, when a UE is connecting to the Wifi, there are two ki= nds=20 service from UE, internet (local breakout) or operators’=20 service
/ internet service (need go through the EPC core=20 network). For the EPC point of view, the UE obtains an IP address from= the=20 EPC network for the operator’s service, which is unique-prefix=20 model. For the wifi point of view, the UE obtains a local IP addres= s for=20 operator’s or internet service (need go through the EPC core=20 network) So we can see two kinds IP addresses will be assigned to=20 UE.
When a UE is connecting to the LTE, unique-prefix model is=20 used.
If the mobile node performs handover from macro network to t= he WLAN=20 network for internet service, I am not sure the unique prefix model should be adopted, exc= ept=20 special scenarios, such as integration or=20 interworking. But you said, “Even in deployment= models where=20 such handovers are no envisioned, such as an WLAN access aggregation arch= itecture=20 with no mobile pa= cket core=20 integration, there are sufficient reasons=20 for adopting = the=20 Unique Prefix model.”. Could you clarify this?


That is one approach, but lets look at some other considerations. The= =20 mobile node is using Stateless Autoconf for address configuration and now t= he=20 operator asks the vendor to do per-user accounting. How does that work ? Th= e=20 gateway will start tracking all the IPv6 address that the mobile node gener= ates=20 ? If it generates like a dozen IPv6 addresses for ephemeral lifetime, will = the=20 gateway track all these addresses ? Will it report all these addresses in=20 Accounting-Start/AAA ? How about LI ? How about we assign a single prefix a= nd=20 track that one prefix ? What is a better approach and what is our recommend= ation=20 ?




2 Section 4.6 Multiple WLAN SSID=20 support
I am wondering whether it is the requir= ement=20 section of Community WiFi. IMHO, community wifi is kind of service or ser= vice=20 requirements.
Multiple WLAN SSID supported in residen= tial wifi=20 hotspots seems like a solution instead of the=20 requirements. Even more, this section is the implemen= tation=20 issue. Do you mind to clarify the real require= ments of=20 community wifi? Then we can think about the IETF soluti= ons, that=20 would be better.


This is a requirement. All most all WLAN networks have this concept of= =20 guest user/guest user service differentiation. The aspect of SSID based=20 separation is one approach. Sure, this can be generalized with the use of=20 HotSpot2.0. But, the key point is service differentiation.



3 Section 4.9 CPE identity and=20 authorization
What about to merge the authorization e= lements=20 to section 4.1, which is authentication and authorization=20 related.

There is this aspect of CPE identity, authorization and then there is = the=20 aspict of service authorization to users. There are good reasons to separat= e=20 them. As we bring some more analysis, this part will be clear. If there is = need,=20 it can be collapsed.



4 Section 4.15=
This section seems like the issues intr= oduced by=20 multiple SSID deployment. My confusion is mentioned in the second=20 comment. I suggest the real requirements of comm= unity=20 wifi should be clarified at first.

These are practical issues related to WiFi deployments in SP context. = This=20 translates into some specific requirements on the protocol layers. Lets dis= cuss=20 further.



5 some suggestion on these requirements= , such=20 as section 4.5, 4.9, etc, mentioned in the=20 draft.
These are SDO areas, and we should conc= entrate=20 on these requirements to identify what IETF can do and state requirements= on=20 IETF work.
What about your=20 opinion?

Yes. At the end we need to see how best the tools we have can be used = for=20 supporting these architectures.

Thanks for your comments.

Regards
Sri




BR
Li
______________________________= _________________
fmc=20 mailing list
fmc@ietf.org
https://www.ietf.org/m= ailman/listinfo/fmc

= --_000_05C81A773E48DD49B181B04BA21A342A27978B02ACHE113484emea1_-- From xueli@huawei.com Fri May 4 03:05:16 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2FA21F8709 for ; Fri, 4 May 2012 03:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XaRWPnlnnTQF for ; Fri, 4 May 2012 03:05:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 549ED21F86F7 for ; Fri, 4 May 2012 03:05:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFV05137; Fri, 04 May 2012 06:05:12 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 03:01:42 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 03:01:40 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.58]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 4 May 2012 17:58:33 +0800 From: Xueli To: Sri Gundavelli Thread-Topic: [fmc] Some comments to the community wifi draft Thread-Index: AQHNKW6yF+s6XrzMQUmDTCaEBrJi/5a5YX2Q Date: Fri, 4 May 2012 09:58:32 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B42C42CC5C@szxeml528-mbs.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B42C42C9BA@szxeml528-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.71] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B42C42CC5Cszxeml528mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "fmc@ietf.org" Subject: Re: [fmc] Some comments to the community wifi draft X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 10:05:16 -0000 --_000_01FE63842C181246BBE4CF183BD159B42C42CC5Cszxeml528mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, Thanks for your response, please see the opinion inline. BR Li From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of Sri G= undavelli Sent: Friday, May 04, 2012 4:53 AM To: Xueli Cc: fmc@ietf.org Subject: Re: [fmc] Some comments to the community wifi draft HI Li, Thanks for the review. inline ... On May 3, 2012, at 2:16 AM, Xueli wrote: Hi, all, I have went through the new draft( http://tools.ietf.org/rfcdiff?url2=3Ddra= ft-gundavelli-v6ops-community-wifi-svcs-04.txt). I have several comments on this draft. Please see as follows. 1 Section 4.1 IPv6 addressing Model for SP WiFi architecture. I agree 3GPP architecture supports unique-prefix model for the mobile node'= s PDN connections. In the context of WiFi, I am not sure this same requirement must be satisfied. It depends. There are very good reasons why IETF made a recommendation to 3= GPP to support Per-MN prefix model. Clearly there are advantages that stand= out. For SP WIFI architectures, the considerations are no different. We al= so need to think from the perspective of the handover from macros access to= trusted WLAN access, the choice of different addressing will make handover= s difficult. [Li XUE] I agree there will be some issues if the prefix assignment models = are different between 3GPP and fixed network. As I mentioned, this depends = on the service and scenario. In interworking and convergence, there is a i= ssue. But in the scenario I said, I think it is no issue. Even in the hando= ver case, if the internet service is changed from macro access to WLAN acce= ss, because the IP address is assigned by different network, the unique-pre= fix model will not impact the handover at all. [Li XUE] As far as I know, it seems difficult to achieve unique-prefix per = UE in fixed network, because it need the extension work on RG/CPE. First, when a UE is connecting to the Wifi, there are two kinds service fro= m UE, internet (local breakout) or operators' service / internet service (need go through the EPC core network). For the EPC point of view, the UE obtains an IP address from the EPC networ= k for the operator's service, which is unique-prefix model. For the wifi point of view, the UE obtains a local IP address for operator'= s or internet service (need go through the EPC core network) So we can see two kinds IP addresses will be assigned to UE. When a UE is connecting to the LTE, unique-prefix model is used. If the mobile node performs handover from macro network to the WLAN network= for internet service, I am not sure the unique prefix model should be adopted, except special sce= narios, such as integration or interworking. But you said, "Even in deployment models where such handovers are no envisi= oned, such as an WLAN access aggregation architecture with no mobile packet core = integration, there are sufficient reasons for adopting the Unique Prefix model.". Could = you clarify this? That is one approach, but lets look at some other considerations. The mobil= e node is using Stateless Autoconf for address configuration and now the op= erator asks the vendor to do per-user accounting. How does that work ? The = gateway will start tracking all the IPv6 address that the mobile node gener= ates ? If it generates like a dozen IPv6 addresses for ephemeral lifetime, = will the gateway track all these addresses ? Will it report all these addre= sses in Accounting-Start/AAA ? How about LI ? How about we assign a single = prefix and track that one prefix ? What is a better approach and what is ou= r recommendation ? [Li XUE] I agree there is an issue for uniform accounting/AAA. Whether we c= an think about the IETF work on protocol layer to resolve it, other than to= force the IPv6 prefix model? 2 Section 4.6 Multiple WLAN SSID support I am wondering whether it is the requirement section of Community WiFi. IMH= O, community wifi is kind of service or service requirements. Multiple WLAN SSID supported in residential wifi hotspots seems like a solu= tion instead of the requirements. Even more, this section is the implementation issue. Do you mind to clarify the real requirements of community wifi? Then we can think about the IETF solutions, that would be better. This is a requirement. All most all WLAN networks have this concept of gues= t user/guest user service differentiation. The aspect of SSID based separat= ion is one approach. Sure, this can be generalized with the use of HotSpot2= .0. But, the key point is service differentiation. [Li XUE] As you said, the aspect of SSID is one approach. I suggest the IET= F work for the service differentiation. 3 Section 4.9 CPE identity and authorization What about to merge the authorization elements to section 4.1, which is aut= hentication and authorization related. There is this aspect of CPE identity, authorization and then there is the a= spict of service authorization to users. There are good reasons to separate= them. As we bring some more analysis, this part will be clear. If there is= need, it can be collapsed. 4 Section 4.15 This section seems like the issues introduced by multiple SSID deployment. = My confusion is mentioned in the second comment. I suggest the real requirements of community wifi should be clarified at fi= rst. These are practical issues related to WiFi deployments in SP context. This = translates into some specific requirements on the protocol layers. Lets dis= cuss further. [Li XUE] sure. 5 some suggestion on these requirements , such as section 4.5, 4.9, etc, me= ntioned in the draft. These are SDO areas, and we should concentrate on these requirements to ide= ntify what IETF can do and state requirements on IETF work. What about your opinion? Yes. At the end we need to see how best the tools we have can be used for s= upporting these architectures. [Li XUE] Agree. Thanks a lot. Thanks for your comments. Regards Sri BR Li _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc --_000_01FE63842C181246BBE4CF183BD159B42C42CC5Cszxeml528mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sri,

Thanks for= your response, please see the opinion inline.

 = ;

BR

Li

 = ;

From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Friday, May 04, 2012 4:53 AM
To: Xueli
Cc: fmc@ietf.org
Subject: Re: [fmc] Some comments to the community wifi draft

 

HI Li,

 

Thanks for the review. inline &= #8230;

 

 

 

 

On May 3, 2012, at 2:16 AM, Xue= li wrote:



Hi, all,

I have went through the new draft( http://= tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops-community-wifi-svcs-04= .txt).

I have several comments on this draft.

Please see as follows.<= /p>

 

1 Section 4.1 IPv6 addressing Model for S= P WiFi architecture.

 

I agree 3GPP architecture supports unique= -prefix model for the mobile node’s PDN connections. In the context of WiFi,

I am not sure this same requirement must = be satisfied.

 

 

It depends. There are very good= reasons why IETF made a recommendation to 3GPP to support Per-MN prefix mo= del. Clearly there are advantages that stand out. For SP WIFI architectures= , the considerations are no different. We also need to think from the perspective of the handover from macros acc= ess to trusted WLAN access, the choice of different addressing will make ha= ndovers difficult.

 

[= Li XUE] I agree there will be = some issues if the prefix assignment models are different between 3GPP and = fixed network. As I mentioned, this depends on the service and scenario. In= interworking and convergence, there is a  issue. But in the scenario I said, I think it is no issue. Even= in the handover case, if the internet service is changed from macro access= to WLAN access, because the IP address is assigned by different network, t= he unique-prefix model will not impact the handover at all.

[= Li XUE] As far as I know, it s= eems difficult to achieve unique-prefix per UE in fixed network, because it= need the extension work on RG/CPE.



First, when a UE is connecting to the Wif= i, there are two kinds service from UE, internet (local breakout) or operators’ service

/ internet service (need go through the E= PC core network).

For the EPC point of view, the UE obtains= an IP address from the EPC network for the operator’s service, which is unique-prefix model.

For the wifi point of view, the UE obtain= s a local IP address for operator’s or internet service (need go through the EPC core network)

So we can see two kinds IP addresses will= be assigned to UE.

 

When a UE is connecting to the LTE, uniqu= e-prefix model is used.

 

If the mobile node performs handover from= macro network to the WLAN network for internet service,<= /p>

I am not sure the unique prefix model sho= uld be adopted, except special scenarios, such as integration or interworking.

But you said, “Even in deployment models where such handovers are no envisioned,<= /span>

such as an WLAN ac= cess aggregation architecture with no mobile packet core integration,

there are sufficie= nt reasons for adopting the Unique Prefix model.”. Could you clarify this?

 

 

 

That is one approach, but lets = look at some other considerations. The mobile node is using Stateless Autoc= onf for address configuration and now the operator asks the vendor to do pe= r-user accounting. How does that work ? The gateway will start tracking all the IPv6 address that the mobile nod= e generates ? If it generates like a dozen IPv6 addresses for ephemeral lif= etime, will the gateway track all these addresses ? Will it report all thes= e addresses in Accounting-Start/AAA ? How about LI ? How about we assign a single prefix and track that one pr= efix ? What is a better approach and what is our recommendation ?

[Li = XUE] I agree th= ere is an issue for uniform accounting/AAA. Whether we can think about the IETF work on protocol layer to resolve it, other than to force t= he IPv6 prefix model?

 

 

 



2 Section 4.6 Mult= iple WLAN SSID support=

I am wondering whe= ther it is the requirement section of Community WiFi. IMHO, community wifi is kind of service or service requirements.

Multiple WLAN SSID= supported in residential wifi hotspots seems like a solution instead of the requirements.

Even more, this se= ction is the implementation issue.

Do you mind to cla= rify the real requirements of community wifi?

Then we can think = about the IETF solutions, that would be better.

 

 

 

This is a requirement. All most= all WLAN networks have this concept of guest user/guest user service diffe= rentiation. The aspect of SSID based separation is one approach. Sure, this= can be generalized with the use of HotSpot2.0. But, the key point is service differentiation.

[Li = XUE] As you said, th= e aspect of SSID is one approach. I suggest the IETF work for the service d= ifferentiation.

 

 



3 Section 4.9 CPE = identity and authorization

What about to merg= e the authorization elements to section 4.1, which is authentication and authorization related.<= /o:p>

 

 

There is this aspect of CPE ide= ntity, authorization and then there is the aspict of service authorization = to users. There are good reasons to separate them. As we bring some more an= alysis, this part will be clear. If there is need, it can be collapsed.

 

 



4 Section 4.15

 

This section seems= like the issues introduced by multiple SSID deployment. My confusion is mentioned in the second comment.

I suggest the real= requirements of community wifi should be clarified at first.=

 

 

These are practical issues rela= ted to WiFi deployments in SP context. This translates into some specific r= equirements on the protocol layers. Lets discuss further.

[Li = XUE] sure.

 

 



5 some suggestion = on these requirements , such as section 4.5, 4.9, etc, mentioned in the draft.<= /p>

These are SDO area= s, and we should concentrate on these requirements to identify what IETF can do and state requirements on IETF work.

What about your op= inion?

 

 

Yes. At the end we need to see = how best the tools we have can be used for supporting these architectures.<= /span>

[Li = XUE] Agree. Thanks a lot.

 

Thanks for your comments.<= /o:p>

 

Regards

Sri

 

 

 



BR

Li

 

 

 

______________________= _________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/= mailman/listinfo/fmc

 

--_000_01FE63842C181246BBE4CF183BD159B42C42CC5Cszxeml528mbschi_-- From sgundave@cisco.com Sun May 6 14:52:50 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099E521F8549 for ; Sun, 6 May 2012 14:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cH7BB1sI7LXT for ; Sun, 6 May 2012 14:52:48 -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 56E6321F851B for ; Sun, 6 May 2012 14:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=45196; q=dns/txt; s=iport; t=1336341168; x=1337550768; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=nvl3UctkaID8Kqgj28U4iiI/IKDLvRQzQatksYL0VaE=; b=K9jOgTxwnmD3zmm/y1AV7JFhhzO0RVmt11/tNGYdfKt2qlOAF5ZsUPw9 3RzBygmihVnjnMxTrwSVe4JLrL4gq6kXtrsmCSQuO8/bdcP2ZohcUFFYJ uvQvOYVn4j/SYLjPiRYMZ86S41Az64dYlGp0xUjiAzf/Qubrxc7Fh0Pq+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFALvxpk+rRDoI/2dsb2JhbAA6AQmCRqcIAYkfgQeCDAEBAQMBAQEBDwFaAQsFCwsSBiABBgcnHwMOBhMUBweFcIF3BAyaU58Cin8PAYUtYwSIZI0agRGNSIFpgwmBPg X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208,217";a="43635982" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 May 2012 21:52:47 +0000 Received: from stealth-10-32-246-214.cisco.com (stealth-10-32-246-214.cisco.com [10.32.246.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q46LqlYj019612; Sun, 6 May 2012 21:52:47 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_012999B2-C810-482C-8CA5-E261F423335D" From: Sri Gundavelli In-Reply-To: <05C81A773E48DD49B181B04BA21A342A27978B02AC@HE113484.emea1.cds.t-internal.com> Date: Sun, 6 May 2012 14:52:46 -0700 Message-Id: <30FD50DF-9B75-4876-8474-FF98B27AB676@cisco.com> References: <01FE63842C181246BBE4CF183BD159B42C42C9BA@szxeml528-mbs.china.huawei.com> <05C81A773E48DD49B181B04BA21A342A27978B02AC@HE113484.emea1.cds.t-internal.com> To: "" X-Mailer: Apple Mail (2.1257) Cc: fmc@ietf.org, xueli@huawei.com Subject: Re: [fmc] Some comments to the community wifi draft X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 21:52:50 -0000 --Apple-Mail=_012999B2-C810-482C-8CA5-E261F423335D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dirk, Thanks for your comments. > he aspect of SSID based separation is one approach. > doesn't this imply that the requirement is to enable service = differentiation, and multiple SSIDs per AP is one potential solution? - Multiple SSID's per Access Point is the trend in many deployments. = Surely, service differentiation based on the SSID is surely one = consideration. But, one may also bring the Hotspot/.11u efforts and may = attempt to provide the same service differentiation using other means. = The approaches of service differentiation may be relevant > But as mentioned the draft is a collection of identified issues and = provides a good basis for FMC work together with others such as = http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01, = http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01, and = http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt. The focus of the draft was to really identify the SP WIFI market and the = solution requirements, so we can see how best we can address these = requirements using existing protocols developed by IETF. This is by no = means a complete spec; the spec will not focus on any specific = tool/protocol extensions. The other drafts such as listed above can = complement the work and be the tools in the over all solution design. = Taking the http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01 = d- it explains how we can support QoS within a localized domain and map = it to the 802.11 access.=20 > Another minor remark: I may have misunderstood the introductory = remarks saying that a mobile operator will see WiFi as "the basis for = offering new wireless broadband services" ... I'd rather think it is = seen as an add-on/completion of the cellular coverage for dedicated = services. It depends. If this access is enabled by an operator who is also a = mobile service operator, then its essentially about expanding the = network coverage and increasing the service availability; its also about = offload. However, for a cable operator with no mobile subscribers, the = primary business incentive is enabling the new service for their own = subscribers and also support a retail model with roaming agreements with = other operators. Both the scenarios are valid IMO. > Beside that only regarding smartphones and tablets almost every new = mobile device is now equipped with IEEE 802.11-based wireless interface = - there are still many new (low-cost) devices without. And I think, at = least in Europe for the time being most of the devices are = pre-configured with a policy to prefer cellular packet data access to = WiFi. :) Back in 2006, there was one of the top mobile handset vendor who used = to disable WLAN interface on their mobile terminals :); then there was = this 2007 and some operators have decided to enable WLAN and also set = the default policy to pick WLAN to cellular; So, operators are learning. = Today, some applications such as FaceTime application is not enabled on = cellular access and there are also new models with respect to moving = away from unlimited service models for cellular, so I assume things will = change in Europe too.=20 Regards=20 Sri On May 4, 2012, at 2:28 AM, = wrote: > Dear Sri, all, > in general I think that the updated draft = http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops-community-wifi= -svcs-04.txt addresses several FMC issues which might be included in the = planned FMC problem statement or requirements draft. I agree with Li = that requirements in different sections on authentication might be = grouped together. > BTW strictly speaking when you say below > The aspect of SSID based separation is one approach. > doesn't this imply that the requirement is to enable service = differentiation, and multiple SSIDs per AP is one potential solution? > But as mentioned the draft is a collection of identified issues and = provides a good basis for FMC work together with others such as = http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01, = http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01, and = http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt. > =20 > What do you think of an attempt to merge aspects addressed within = them? > =20 > Another minor remark: I may have misunderstood the introductory = remarks saying that a mobile operator will see WiFi as "the basis for = offering new wireless broadband services" ... I'd rather think it is = seen as an add-on/completion of the cellular coverage for dedicated = services. Beside that only regarding smartphones and tablets almost = every new mobile device is now equipped with IEEE 802.11-based wireless = interface - there are still many new (low-cost) devices without. And I = think, at least in Europe for the time being most of the devices are = pre-configured with a policy to prefer cellular packet data access to = WiFi. > =20 > Best regards=20 > Dirk > =20 > Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von = Sri Gundavelli > Gesendet: Donnerstag, 3. Mai 2012 22:53 > An: Xueli > Cc: fmc@ietf.org > Betreff: Re: [fmc] Some comments to the community wifi draft >=20 > HI Li, >=20 > Thanks for the review. inline =85 >=20 >=20 >=20 >=20 > On May 3, 2012, at 2:16 AM, Xueli wrote: >=20 >> Hi, all, >> I have went through the new draft( = http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops-community-wifi= -svcs-04.txt). >> I have several comments on this draft. >> Please see as follows. >> 1 Section 4.1 IPv6 addressing Model for SP WiFi architecture. >> I agree 3GPP architecture supports unique-prefix model for the mobile = node=92s PDN connections. In the context of WiFi, >> I am not sure this same requirement must be satisfied. >=20 >=20 > It depends. There are very good reasons why IETF made a recommendation = to 3GPP to support Per-MN prefix model. Clearly there are advantages = that stand out. For SP WIFI architectures, the considerations are no = different. We also need to think from the perspective of the handover = from macros access to trusted WLAN access, the choice of different = addressing will make handovers difficult. >=20 >=20 >=20 >> First, when a UE is connecting to the Wifi, there are two kinds = service from UE, internet (local breakout) or operators=92 service >> / internet service (need go through the EPC core network). >> For the EPC point of view, the UE obtains an IP address from the EPC = network for the operator=92s service, which is unique-prefix model. >> For the wifi point of view, the UE obtains a local IP address for = operator=92s or internet service (need go through the EPC core network) >> So we can see two kinds IP addresses will be assigned to UE. >> When a UE is connecting to the LTE, unique-prefix model is used. >> If the mobile node performs handover from macro network to the WLAN = network for internet service, >> I am not sure the unique prefix model should be adopted, except = special scenarios, such as integration or interworking. >> But you said, =93Even in deployment models where such handovers are = no envisioned, >> such as an WLAN access aggregation architecture with no mobile packet = core integration, >> there are sufficient reasons for adopting the Unique Prefix model.=94. = Could you clarify this? >=20 >=20 > That is one approach, but lets look at some other considerations. The = mobile node is using Stateless Autoconf for address configuration and = now the operator asks the vendor to do per-user accounting. How does = that work ? The gateway will start tracking all the IPv6 address that = the mobile node generates ? If it generates like a dozen IPv6 addresses = for ephemeral lifetime, will the gateway track all these addresses ? = Will it report all these addresses in Accounting-Start/AAA ? How about = LI ? How about we assign a single prefix and track that one prefix ? = What is a better approach and what is our recommendation ? >=20 >=20 >=20 >=20 >> 2 Section 4.6 Multiple WLAN SSID support >> I am wondering whether it is the requirement section of Community = WiFi. IMHO, community wifi is kind of service or service requirements. >> Multiple WLAN SSID supported in residential wifi hotspots seems like = a solution instead of the requirements. >> Even more, this section is the implementation issue. >> Do you mind to clarify the real requirements of community wifi? >> Then we can think about the IETF solutions, that would be better. >=20 >=20 > This is a requirement. All most all WLAN networks have this concept of = guest user/guest user service differentiation. The aspect of SSID based = separation is one approach. Sure, this can be generalized with the use = of HotSpot2.0. But, the key point is service differentiation. >=20 >=20 >=20 >> 3 Section 4.9 CPE identity and authorization >> What about to merge the authorization elements to section 4.1, which = is authentication and authorization related. >=20 > There is this aspect of CPE identity, authorization and then there is = the aspict of service authorization to users. There are good reasons to = separate them. As we bring some more analysis, this part will be clear. = If there is need, it can be collapsed. >=20 >=20 >=20 >> 4 Section 4.15 >> This section seems like the issues introduced by multiple SSID = deployment. My confusion is mentioned in the second comment. >> I suggest the real requirements of community wifi should be clarified = at first. >=20 > These are practical issues related to WiFi deployments in SP context. = This translates into some specific requirements on the protocol layers. = Lets discuss further. >=20 >=20 >=20 >> 5 some suggestion on these requirements , such as section 4.5, 4.9, = etc, mentioned in the draft. >> These are SDO areas, and we should concentrate on these requirements = to identify what IETF can do and state requirements on IETF work. >> What about your opinion? >=20 > Yes. At the end we need to see how best the tools we have can be used = for supporting these architectures. >=20 > Thanks for your comments. >=20 > Regards > Sri >=20 >=20 >=20 >=20 >> BR >> Li >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc >=20 --Apple-Mail=_012999B2-C810-482C-8CA5-E261F423335D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Dirk,

Thanks for your = comments.

he aspect of SSID based separation is one = approach.
doesn't this imply that the = requirement is to enable service differentiation, and multiple SSIDs per = AP is one potential = solution?

- Multiple SSID's per Access Point is the trend in many = deployments. Surely, service differentiation based on the SSID is surely = one consideration. But, one may also bring the Hotspot/.11u efforts and = may attempt to provide the same service differentiation using other = means. The approaches of service differentiation may be = relevant

But as = mentioned the draft is a collection of identified issues and provides a = good basis for FMC work together with others such = as http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analy= sis-01,  <= font color=3D"#0000ff" size=3D"2">http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01, and http://t= ools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt.
<= /div>

The focus of the draft was to = really identify the SP WIFI market and the solution requirements, so we = can see how best we can address these requirements using existing = protocols developed by IETF. This is by no means a complete spec; the = spec will not focus on any specific tool/protocol extensions.  The = other drafts such as listed above can complement the work and be the = tools in the over all solution design. Taking the  http= ://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01 <= /font>d- it explains how we can support QoS within a = localized domain and map it to the 802.11 = access. 

Another minor remark: I may have misunderstood the = introductory remarks saying that a mobile operator will see WiFi as "the = basis for offering new wireless broadband services"  ... I'd rather think it is seen as an add-on/completion of the = cellular coverage for dedicated = services.
It depends. If this access is enabled by an operator who is = also a mobile service operator, then its essentially about expanding the = network coverage and increasing the service availability; its also about = offload.  However,  for a cable operator with no mobile = subscribers, the primary business incentive is enabling the new service = for their own subscribers and also support a retail model with roaming = agreements with other operators. Both the scenarios are valid = IMO.

Beside that only regarding = smartphones and tablets almost every new mobile device is now = equipped with IEEE 802.11-based wireless interface - there are still many new (low-cost) devices without. = And I think, at = least in Europe for the time being most of the devices = are pre-configured with a policy to prefer = cellular packet = data access to = WiFi.

:)= Back in 2006, there was one of the top mobile handset vendor who used = to disable WLAN interface on their mobile terminals :);  then there = was this 2007 and some operators have decided to enable WLAN and also = set the default policy to pick WLAN to cellular; So, operators are = learning. Today, some applications such as FaceTime application is not = enabled on cellular access and there are also new models with respect to = moving away from unlimited service models for cellular, so I assume = things will change in Europe = too. 


Regards 
Sri




= On May 4, 2012, at 2:28 AM, <Dirk.von-Hugo@telekom.de> = <Dirk.von-Hugo@telekom.de> = wrote:

Dear Sri, = all,
in general I think that the updated=20= draft http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops= -community-wifi-svcs-04.txt addresses several FMC = issues which might be included = in the planned FMC problem = statement or requirements draft.=20 I agree with Li that requirements in different sections on = authentication might=20 be grouped together.
BTW strictly=20 speaking when you  say below
The aspect of SSID based separation is one=20= approach.
doesn't = this=20 imply that the requirement is to enable service differentiation, = and=20 multiple SSIDs per AP is one potential = solution?
But as = mentioned the=20 draft is a collection of identified issues and provides a good basis for = FMC=20 work together with others such as http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analy= sis-01,  <= font color=3D"#0000ff" size=3D"2">http://tools.ietf.org/html/draft-liebsch-netext-pmip6-qos-01,=20 and http://t= ools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt.=20
 
What do = you think of an=20 attempt to merge aspects addressed within = them?
 
Another minor remark: I may=20 have = misunderstood the=20 introductory remarks saying that a mobile operator will see WiFi as "the = basis=20 for offering new wireless broadband services"  ... I'd rather think it is seen as=20 an add-on/completion of the cellular coverage for dedicated=20= services. Beside that only regarding smartphones and tablets = almost every=20 new mobile device is now equipped with IEEE 802.11-based wireless=20 interface - there are still many=20= new (low-cost) devices without. And I think, at least in Europe for the = time being=20 most of the devices are pre-configured with a policy to prefer = cellular packet data = access to = WiFi.
 
Best=20 regards
Dirk=20
 
Von: fmc-bounces@ietf.org=20 [mailto:fmc-bounces@ietf.org] Im Auftrag von Sri=20 Gundavelli
Gesendet: Donnerstag, 3. Mai 2012 = 22:53
An:=20 Xueli
Cc: fmc@ietf.org
Betreff: Re: = [fmc] Some comments to=20 the community wifi draft

HI Li,

Thanks for the review. inline =85




On May 3, 2012, at 2:16 AM, Xueli wrote:

Hi, = all,
I have = several comments on this draft.
Please see = as follows.
1 Section = 4.1 IPv6 addressing Model for SP WiFi=20 architecture.
I agree = 3GPP architecture supports unique-prefix model for the=20 mobile node=92s PDN connections. In the context of = WiFi,
I am not = sure this same requirement must be=20 satisfied.


It depends. There are very good reasons why IETF made a = recommendation to=20 3GPP to support Per-MN prefix model. Clearly there are advantages that = stand=20 out. For SP WIFI architectures, the considerations are no different. We = also=20 need to think from the perspective of the handover from macros access to = trusted=20 WLAN access, the choice of different addressing will make handovers=20 difficult.



First, when = a UE is connecting to the Wifi, there are two kinds=20 service from UE, internet (local breakout) or operators=92=20 service
/ internet = service (need go through the EPC core=20 network).
For the EPC = point of view, the UE obtains an IP address from the=20 EPC network for the operator=92s service, which is unique-prefix=20 model.
For the = wifi point of view, the UE obtains a local IP address for=20 operator=92s or internet service (need go through the EPC core=20 network)
So we can = see two kinds IP addresses will be assigned to=20 UE.
When a UE = is connecting to the LTE, unique-prefix model is=20 used.
If the = mobile node performs handover from macro network to the WLAN=20 network for internet service,
I am not = sure the unique prefix model should be adopted, except=20 special scenarios, such as integration or=20 interworking.
But you = said, =93Even in deployment models where=20 such handovers are no envisioned,
such as an WLAN access aggregation architecture=20 with no mobile= packet core=20 integration,
there are sufficient reasons=20 for adopting the=20 Unique Prefix model.=94. Could you clarify = this?


That is one approach, but lets look at some other considerations. = The=20 mobile node is using Stateless Autoconf for address configuration and = now the=20 operator asks the vendor to do per-user accounting. How does that work ? = The=20 gateway will start tracking all the IPv6 address that the mobile node = generates=20 ? If it generates like a dozen IPv6 addresses for ephemeral lifetime, = will the=20 gateway track all these addresses ? Will it report all these addresses = in=20 Accounting-Start/AAA ? How about LI ? How about we assign a single = prefix and=20 track that one prefix ? What is a better approach and what is our = recommendation=20 ?




2 Section 4.6 Multiple WLAN SSID=20 support
I am wondering whether it is the requirement=20 section of Community WiFi. IMHO, community wifi is kind of service or = service=20 requirements.
Multiple WLAN SSID supported in residential wifi=20 hotspots seems like a solution instead of the=20 requirements.
Even more, this section is the implementation=20 issue.
Do you mind to clarify the real requirements of=20 community wifi?
Then we can think about the IETF solutions, that=20 would be better.


This is a requirement. All most all WLAN networks have this concept = of=20 guest user/guest user service differentiation. The aspect of SSID based=20= separation is one approach. Sure, this can be generalized with the use = of=20 HotSpot2.0. But, the key point is service differentiation.



3 Section 4.9 CPE identity and=20 authorization
What about to merge the authorization elements=20 to section 4.1, which is authentication and authorization=20 related.

There is this aspect of CPE identity, authorization and then there = is the=20 aspict of service authorization to users. There are good reasons to = separate=20 them. As we bring some more analysis, this part will be clear. If there = is need,=20 it can be collapsed.



4 Section 4.15
This section seems like the issues introduced by=20 multiple SSID deployment. My confusion is mentioned in the second=20 comment.
I suggest the real requirements of community=20 wifi should be clarified at first.

These are practical issues related to WiFi deployments in SP = context. This=20 translates into some specific requirements on the protocol layers. Lets = discuss=20 further.



5 some suggestion on these requirements , such=20 as section 4.5, 4.9, etc, mentioned in the=20 draft.
These are SDO areas, and we should concentrate=20 on these requirements to identify what IETF can do and state = requirements on=20 IETF work.
What about your=20 opinion?

Yes. At the end we need to see how best the tools we have can be = used for=20 supporting these architectures.

Thanks for your comments.

Regards
Sri




BR
Li
_____________________________= __________________
fmc=20 mailing list
fmc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/fmc

=

= --Apple-Mail=_012999B2-C810-482C-8CA5-E261F423335D-- From sgundave@cisco.com Sun May 6 14:55:52 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD8521F855B for ; Sun, 6 May 2012 14:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TA83icMjP4xV for ; Sun, 6 May 2012 14:55:50 -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 85C6721F8551 for ; Sun, 6 May 2012 14:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=56404; q=dns/txt; s=iport; t=1336341350; x=1337550950; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=VKQN3cdfZGpGEBapuqo4SbXGnIzyuKr9z96fNHvDoNw=; b=P1ske+N89qJb3smkf3TmdNmI+++jFEfIOJZp9JiCr1F3NHI2sf/PtQxE h3xGRUHvGj77kC6uXk4ttEwF5DcRb54nHbSMMf4AyNW9sOQ1deBue4JmD MPzQeJUY6sly80lmfhxXLEUI2gqwqyuea91RbMBtY6feEYHBeoEmK+IfJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKvypk+rRDoJ/2dsb2JhbAA6AQmCRrAogQeCDAEBAQMBAQEBDwFbCwULCxEBAwEBASABBgcnHwMGCAYRAhQHB4VwgXcEDJpTnwGKfw8BhS1jBIhkjRqBEY1IgWmDCR6BIA X-IronPort-AV: E=Sophos;i="4.75,540,1330905600"; d="scan'208,217";a="41153609" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 06 May 2012 21:55:50 +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 q46LtnJK021757; Sun, 6 May 2012 21:55:49 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C49D63D-2ADF-4BFB-A6B8-2145BAB5F20B" From: Sri Gundavelli In-Reply-To: <01FE63842C181246BBE4CF183BD159B42C42CC5C@szxeml528-mbs.china.huawei.com> Date: Sun, 6 May 2012 14:55:49 -0700 Message-Id: References: <01FE63842C181246BBE4CF183BD159B42C42C9BA@szxeml528-mbs.china.huawei.com> <01FE63842C181246BBE4CF183BD159B42C42CC5C@szxeml528-mbs.china.huawei.com> To: Xueli X-Mailer: Apple Mail (2.1257) Cc: "fmc@ietf.org" Subject: Re: [fmc] Some comments to the community wifi draft X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 21:55:52 -0000 --Apple-Mail=_1C49D63D-2ADF-4BFB-A6B8-2145BAB5F20B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Li, [Li XUE] I agree there is an issue for uniform accounting/AAA. Whether = we can think about the IETF work on protocol layer to resolve it, other = than to force the IPv6 prefix model? =20 There is nothing like forcing a specific approach, but rather list out = the issues and recommend a specific approach. > [Li XUE] As far as I know, it seems difficult to achieve unique-prefix = per UE in fixed network, because it need the extension work on RG/CPE. =20 I'm not sure, but we can discuss this in the solution context. Regards Sri On May 4, 2012, at 2:58 AM, Xueli wrote: > Hi Sri, > Thanks for your response, please see the opinion inline. > =20 > BR > Li > =20 > From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of = Sri Gundavelli > Sent: Friday, May 04, 2012 4:53 AM > To: Xueli > Cc: fmc@ietf.org > Subject: Re: [fmc] Some comments to the community wifi draft > =20 > HI Li, > =20 > Thanks for the review. inline =85 > =20 > =20 > =20 > =20 > On May 3, 2012, at 2:16 AM, Xueli wrote: >=20 >=20 > Hi, all, > I have went through the new draft( = http://tools.ietf.org/rfcdiff?url2=3Ddraft-gundavelli-v6ops-community-wifi= -svcs-04.txt). > I have several comments on this draft. > Please see as follows. > =20 > 1 Section 4.1 IPv6 addressing Model for SP WiFi architecture. > =20 > I agree 3GPP architecture supports unique-prefix model for the mobile = node=92s PDN connections. In the context of WiFi, > I am not sure this same requirement must be satisfied. > =20 > =20 > It depends. There are very good reasons why IETF made a recommendation = to 3GPP to support Per-MN prefix model. Clearly there are advantages = that stand out. For SP WIFI architectures, the considerations are no = different. We also need to think from the perspective of the handover = from macros access to trusted WLAN access, the choice of different = addressing will make handovers difficult. > =20 > [Li XUE] I agree there will be some issues if the prefix assignment = models are different between 3GPP and fixed network. As I mentioned, = this depends on the service and scenario. In interworking and = convergence, there is a issue. But in the scenario I said, I think it = is no issue. Even in the handover case, if the internet service is = changed from macro access to WLAN access, because the IP address is = assigned by different network, the unique-prefix model will not impact = the handover at all. > [Li XUE] As far as I know, it seems difficult to achieve unique-prefix = per UE in fixed network, because it need the extension work on RG/CPE. >=20 >=20 > First, when a UE is connecting to the Wifi, there are two kinds = service from UE, internet (local breakout) or operators=92 service > / internet service (need go through the EPC core network). > For the EPC point of view, the UE obtains an IP address from the EPC = network for the operator=92s service, which is unique-prefix model. > For the wifi point of view, the UE obtains a local IP address for = operator=92s or internet service (need go through the EPC core network) > So we can see two kinds IP addresses will be assigned to UE. > =20 > When a UE is connecting to the LTE, unique-prefix model is used. > =20 > If the mobile node performs handover from macro network to the WLAN = network for internet service, > I am not sure the unique prefix model should be adopted, except = special scenarios, such as integration or interworking. > But you said, =93Even in deployment models where such handovers are no = envisioned, > such as an WLAN access aggregation architecture with no mobile packet = core integration, > there are sufficient reasons for adopting the Unique Prefix model.=94. = Could you clarify this? > =20 > =20 > =20 > That is one approach, but lets look at some other considerations. The = mobile node is using Stateless Autoconf for address configuration and = now the operator asks the vendor to do per-user accounting. How does = that work ? The gateway will start tracking all the IPv6 address that = the mobile node generates ? If it generates like a dozen IPv6 addresses = for ephemeral lifetime, will the gateway track all these addresses ? = Will it report all these addresses in Accounting-Start/AAA ? How about = LI ? How about we assign a single prefix and track that one prefix ? = What is a better approach and what is our recommendation ? > [Li XUE] I agree there is an issue for uniform accounting/AAA. Whether = we can think about the IETF work on protocol layer to resolve it, other = than to force the IPv6 prefix model? > =20 > =20 > =20 >=20 >=20 > 2 Section 4.6 Multiple WLAN SSID support > I am wondering whether it is the requirement section of Community = WiFi. IMHO, community wifi is kind of service or service requirements. > Multiple WLAN SSID supported in residential wifi hotspots seems like a = solution instead of the requirements. > Even more, this section is the implementation issue. > Do you mind to clarify the real requirements of community wifi? > Then we can think about the IETF solutions, that would be better. > =20 > =20 > =20 > This is a requirement. All most all WLAN networks have this concept of = guest user/guest user service differentiation. The aspect of SSID based = separation is one approach. Sure, this can be generalized with the use = of HotSpot2.0. But, the key point is service differentiation. > [Li XUE] As you said, the aspect of SSID is one approach. I suggest = the IETF work for the service differentiation. > =20 > =20 >=20 >=20 > 3 Section 4.9 CPE identity and authorization > What about to merge the authorization elements to section 4.1, which = is authentication and authorization related. > =20 > =20 > There is this aspect of CPE identity, authorization and then there is = the aspict of service authorization to users. There are good reasons to = separate them. As we bring some more analysis, this part will be clear. = If there is need, it can be collapsed. > =20 > =20 >=20 >=20 > 4 Section 4.15 > =20 > This section seems like the issues introduced by multiple SSID = deployment. My confusion is mentioned in the second comment. > I suggest the real requirements of community wifi should be clarified = at first. > =20 > =20 > These are practical issues related to WiFi deployments in SP context. = This translates into some specific requirements on the protocol layers. = Lets discuss further. > [Li XUE] sure. > =20 > =20 >=20 >=20 > 5 some suggestion on these requirements , such as section 4.5, 4.9, = etc, mentioned in the draft. > These are SDO areas, and we should concentrate on these requirements = to identify what IETF can do and state requirements on IETF work. > What about your opinion? > =20 > =20 > Yes. At the end we need to see how best the tools we have can be used = for supporting these architectures. > [Li XUE] Agree. Thanks a lot. > =20 > Thanks for your comments. > =20 > Regards > Sri > =20 > =20 > =20 >=20 >=20 > BR > Li > =20 > =20 > =20 > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > =20 --Apple-Mail=_1C49D63D-2ADF-4BFB-A6B8-2145BAB5F20B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Li,

[Li = XUE] I agree there is an issue for uniform accounting/AAA. = Whether we can think about the IETF work on protocol layer to resolve = it, other than to force the IPv6 prefix = model?
 
There is nothing like forcing = a specific approach, but rather list out the issues and recommend a = specific approach.


[Li = XUE] As far as I know, it seems difficult to achieve = unique-prefix per UE in fixed network, because it need the extension = work on = RG/CPE.
 
I'm not sure, but we can = discuss this in the solution context.


Regards
Sri



On May 4, 2012, at = 2:58 AM, Xueli wrote:

Hi = Sri,
Thanks for your response, please see the opinion = inline.
 
Li
From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org]=  On Behalf Of Sri = Gundavelli
Sent: Friday, May 04, 2012 4:53 = AM
To: Xueli
Cc: fmc@ietf.org
Subject: Re: [fmc] Some comments to = the community wifi draft
 
HI = Li,
 
Thanks for the review. inline = =85
 
 
 
 
On May 3, 2012, at 2:16 AM, Xueli = wrote:















= --Apple-Mail=_1C49D63D-2ADF-4BFB-A6B8-2145BAB5F20B-- From sarikaya2012@gmail.com Fri May 11 03:44:00 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1948D21F85E6 for ; Fri, 11 May 2012 03:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 MQxEMQ6B1Q76 for ; Fri, 11 May 2012 03:43:59 -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 A1F9F21F85E5 for ; Fri, 11 May 2012 03:43:59 -0700 (PDT) Received: by yhq56 with SMTP id 56so2988939yhq.31 for ; Fri, 11 May 2012 03:43:59 -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=kheJ2NyTGgIPrt7G8HA+/gJTuao9HGhv8BZEL42Bcmg=; b=j6bz4l79WwYIUW3sbfCqLF0Jk15xdLqg8MjUlPkNR/bjNhqqu7WURPp9p7Rf6HGWK6 wId9QBK67aIB2v0ai6ouZE4T6fUh6kfI6wbZnAK3PL7z/7PYg+dg5jsGWT0Wh04LsDQa nnu+GfBXs+Vmq5e2u2QgBA9Mffr1UvOl9MQJjj1PrbtiNBBneh01r/BsPczFfUEXD8SO BtkiF3C5+slT/nURMH2nA7KPMk07cW9WtsUCD8RvJhfvUrhkVweIy5aqPioFzcio4zUQ GXCvRefRFn2UQ/cLTCiPN0Urn9DiY0pf+wOcpwbWYkfnqbh5JeV07VaThwl5AnfmK3bg zEYQ== MIME-Version: 1.0 Received: by 10.50.40.193 with SMTP id z1mr596307igk.0.1336733038988; Fri, 11 May 2012 03:43:58 -0700 (PDT) Received: by 10.231.78.10 with HTTP; Fri, 11 May 2012 03:43:58 -0700 (PDT) Date: Fri, 11 May 2012 05:43:58 -0500 Message-ID: From: Behcet Sarikaya To: fmc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Dirk.von-Hugo@telekom.de Subject: [fmc] Call for volunteers X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 10:44:00 -0000 Hi all, We are looking for volunteers to write a requirements draft. The work will be based on the points already posted on the list by Med. 1+ persons is needed. If interested drop a note to Dirk and me. Regards, Behcet From tso@zteusa.com Fri May 11 03:48:53 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061A521F85E5; Fri, 11 May 2012 03:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] 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 9sneideRWLph; Fri, 11 May 2012 03:48:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C7C7B21F8570; Fri, 11 May 2012 03:48:48 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Fri, 11 May 2012 18:05:40 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 39707.2816692506; Fri, 11 May 2012 18:48:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q4BAmVue014321; Fri, 11 May 2012 18:48:31 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: sarikaya@ieee.org MIME-Version: 1.0 X-KeepSent: AEC8E6A8:AD796B0B-882579FB:003B3883; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Fri, 11 May 2012 03:48:04 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-11 18:48:34, Serialize complete at 2012-05-11 18:48:34 Content-Type: multipart/alternative; boundary="=_alternative 003B5C33882579FB_=" X-MAIL: mse02.zte.com.cn q4BAmVue014321 Cc: fmc-bounces@ietf.org, fmc@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [fmc] Call for volunteers X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 10:48:53 -0000 This is a multipart message in MIME format. --=_alternative 003B5C33882579FB_= Content-Type: text/plain; charset="US-ASCII" Dear Behcet, May I ask, what and where are the problem statements? What the requirements are for? Thanks. Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 05/11/2012 03:43 AM Please respond to sarikaya@ieee.org To fmc@ietf.org cc Dirk.von-Hugo@telekom.de Subject [fmc] Call for volunteers Hi all, We are looking for volunteers to write a requirements draft. The work will be based on the points already posted on the list by Med. 1+ persons is needed. If interested drop a note to Dirk and me. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003B5C33882579FB_= Content-Type: text/html; charset="US-ASCII" Dear Behcet,

May I ask, what and where are the problem statements?  What the requirements are for?

Thanks.
Tricci




Behcet Sarikaya <sarikaya2012@gmail.com>
Sent by: fmc-bounces@ietf.org

05/11/2012 03:43 AM
Please respond to
sarikaya@ieee.org
To
fmc@ietf.org
cc
Dirk.von-Hugo@telekom.de
Subject
[fmc] Call for volunteers





Hi all,

We are looking for volunteers to write a requirements draft. The work
will be based on the points already posted on the list by Med.
1+ persons is needed. If interested drop a note to Dirk and me.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003B5C33882579FB_=-- From soohongp@gmail.com Fri May 11 04:14:03 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AAA21F85DD for ; Fri, 11 May 2012 04:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 Y0-HLgVFjk4U for ; Fri, 11 May 2012 04:14:02 -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 9064821F85DB for ; Fri, 11 May 2012 04:14:02 -0700 (PDT) Received: by bkty8 with SMTP id y8so2469237bkt.31 for ; Fri, 11 May 2012 04:14:01 -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=B6t0w8bJ7UUvI2yzofXrT4pd9N/qWtz+qP0gZNkG34o=; b=02nhBkMCgjphZ4Jonkt05VjvE7Lg3KG9Q3P25kmuQZ4F1iR1pYo4tw7YdU5VhqkKna W852USbocxueHiznHM2v7P5S2nFkZGaaQlylNf/z6PDPGpbobQzGtxOcIK8Fgmugn3GX i1Tq8yOBf7Agstp78ydfSiUVjEzR7LtoLGGc6l9HITd1ylmN+qsvMb88LbfN8Bkq4fKt fySZiKiANM1mjigXWB37bzeTBuoyqlyHvNhi5nr5NgETjt1oG8XdYYLGZrQWniQbkpiK M6uM2MZ+l2DiQ/6wzQQYic3SHoXAl6kKRIBBgYJ9FzxwtHPtoGyhj6LeYFrvacxvwlar VVWA== MIME-Version: 1.0 Received: by 10.204.153.204 with SMTP id l12mr4643162bkw.49.1336734841700; Fri, 11 May 2012 04:14:01 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Fri, 11 May 2012 04:14:01 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Fri, 11 May 2012 04:14:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 May 2012 20:14:01 +0900 Message-ID: From: Daniel Park To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=0015175ce0bc66036904bfc0d511 Cc: fmc@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [fmc] Call for volunteers X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 11:14:03 -0000 --0015175ce0bc66036904bfc0d511 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable I can help if needed since I wrote up several IPTV papers regarding heterogeneous networks. You can find it with Mobile IPTV keyword in wikipedia. Regards. Soohong Daniel Park from my Galaxy Note 2012. 5. 11. =BF=C0=C8=C4 7:44=BF=A1 "Behcet Sarikaya" =B4=D4=C0=CC =C0=DB=BC=BA: > Hi all, > > We are looking for volunteers to write a requirements draft. The work > will be based on the points already posted on the list by Med. > 1+ persons is needed. If interested drop a note to Dirk and me. > > Regards, > > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > --0015175ce0bc66036904bfc0d511 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable

I can help if needed since I wrote up several IPTV papers regarding hete= rogeneous networks. You can find it with Mobile IPTV keyword in wikipedia.<= /p>

Regards.

Soohong Daniel Park from my Galaxy Note

2012. 5. 11. =BF=C0=C8=C4 7:44=BF=A1 "Behce= t Sarikaya" <sarikaya2012= @gmail.com>=B4=D4=C0=CC =C0=DB=BC=BA:
Hi all,

We are looking for volunteers to write a requirements draft. The work
will be based on the points already posted on the list by Med.
1+ persons is needed. If interested drop a note to Dirk and me.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/fmc
--0015175ce0bc66036904bfc0d511-- From carlw@mcsr-labs.org Fri May 11 08:06:23 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534CB21F84FB for ; Fri, 11 May 2012 08:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.248 X-Spam-Level: * X-Spam-Status: No, score=1.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] 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 tyRsSIBoGzxN for ; Fri, 11 May 2012 08:06:16 -0700 (PDT) Received: from mail149c38.carrierzone.com (mail149c38.carrierzone.com [66.175.56.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16D21F84FA for ; Fri, 11 May 2012 08:06:15 -0700 (PDT) X-Authenticated-User: carlw.mcsr-labs.org Received: from [192.168.1.12] ([69.241.25.0]) (authenticated bits=0) by mail149c38.carrierzone.com (8.13.6/8.13.1) with ESMTP id q4BF69ZA005195; Fri, 11 May 2012 15:06:10 +0000 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 11 May 2012 11:05:53 -0400 From: Carl Williams To: Message-ID: Thread-Topic: [fmc] Call for volunteers In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3419579171_2485548" X-CSC: 0 X-CHA: v=1.1 cv=mwlFAaDA+ikO7kMzgKjtEAO1h4y7OmPpnUzlklLDj+M= c=1 sm=1 a=W-hxRJO8TvsA:10 a=Gzqcop6RMF0A:10 a=8wjbuZIaoH7ngIPs8+0CXA==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=ERbfXFcYzC6M5BC5nkMA:9 a=cDtDGmh7zDbMsIV0kTYA:7 a=Spabb166XhwA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=hsvIp2lasPRoqV10EPUA:9 a=Ey8Hw7eOvUf8fBn_OQ4A:7 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=8wjbuZIaoH7ngIPs8+0CXA==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A010205.4FAD2AE4.0003, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: fmc@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [fmc] Call for volunteers X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 15:06:23 -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_3419579171_2485548 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Hi Behcet, I think you should have a clear problem statement that everyone agrees about the problem space =A1=A9 that must be done =A1=A9 otherwise what are your requirements for. Carl 2012. 5. 11. =BF=C0=C8=C4 7:44=BF=A1 "Behcet Sarikaya" =B4=D4=C0=CC =C0=DB=BC= =BA: > Hi all, >=20 > We are looking for volunteers to write a requirements draft. The work > will be based on the points already posted on the list by Med. > 1+ persons is needed. If interested drop a note to Dirk and me. >=20 > Regards, >=20 > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc --B_3419579171_2485548 Content-type: text/html; charset="EUC-KR" Content-transfer-encoding: quoted-printable

Hi Behcet,

  I think you should have a clear problem statem= ent that everyone agrees about the problem space – that must be done &= #8211; otherwise what are your requirements for.

Ca= rl


2012. 5. 11. =BF=C0=C8=C4 7:44=BF=A1 "Behcet = Sarikaya" <sarikaya2012@gmail.com= >=B4=D4=C0=CC =C0=DB=BC=BA:
Hi all,

We are looking for volunteers to write a requirements draft. The work
will be based on the points already posted on the list by Med.
1+ persons is needed. If interested drop a note to Dirk and me.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.i= etf.org/mailman/listinfo/fmc
_______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/ma= ilman/listinfo/fmc --B_3419579171_2485548-- From charliep@computer.org Fri May 11 10:47:43 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7FB21F8527 for ; Fri, 11 May 2012 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gH3CBca+Dxdr for ; Fri, 11 May 2012 10:47:42 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6C78721F8517 for ; Fri, 11 May 2012 10:47:42 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.255.200]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SStwK-0008Hn-Uq; Fri, 11 May 2012 13:47:41 -0400 Message-ID: <4FAD50AC.7020305@computer.org> Date: Fri, 11 May 2012 10:47:24 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Meadows User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carl Williams References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070701080600020900060108" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f2f90b9286150ec8f0aa9093948e2057350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: sarikaya@ieee.org, fmc@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [fmc] Call for volunteers X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 17:47:43 -0000 This is a multi-part message in MIME format. --------------070701080600020900060108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, I am interested to volunteer to help write the draft. I'm catching up on the mailing list discussion today. Regards, Charlie P. On 5/11/2012 8:05 AM, Carl Williams wrote: > > Hi Behcet, > > I think you should have a clear problem statement that everyone > agrees about the problem space -- that must be done -- otherwise what > are your requirements for. > > Carl > > > 2012. 5. 11. ?? 7:44? "Behcet Sarikaya" > ?? ??: > > Hi all, > > We are looking for volunteers to write a requirements draft. The work > will be based on the points already posted on the list by Med. > 1+ persons is needed. If interested drop a note to Dirk and me. > > Regards, > > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > _______________________________________________ fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. -- Regards, Charlie P. --------------070701080600020900060108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello folks,

I am interested to volunteer to help write the draft.  I'm catching up on the mailing list discussion today.

Regards,
Charlie P.

On 5/11/2012 8:05 AM, Carl Williams wrote:

Hi Behcet,

  I think you should have a clear problem statement that everyone agrees about the problem space – that must be done – otherwise what are your requirements for.

Carl


2012. 5. 11. 오후 7:44에 "Behcet Sarikaya" <sarikaya2012@gmail.com> 님이 작성:
Hi all,

We are looking for volunteers to write a requirements draft. The work
will be based on the points already posted on the list by Med.
1+ persons is needed. If interested drop a note to Dirk and me.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc 

_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc



-- 
Regards,
Charlie P.

-- 
Regards,
Charlie P.
--------------070701080600020900060108-- From charliep@computer.org Fri May 11 13:43:01 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DE321F86F1 for ; Fri, 11 May 2012 13:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 opjJKyiZ4UGT for ; Fri, 11 May 2012 13:43:00 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id B940B21F86D8 for ; Fri, 11 May 2012 13:42:59 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.255.200]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SSwfy-0000Cv-VB; Fri, 11 May 2012 16:42:59 -0400 Message-ID: <4FAD79C3.8010707@computer.org> Date: Fri, 11 May 2012 13:42:43 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Meadows User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carl Williams References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090104000100030807050605" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8666ff0a208987f415383ac82249a88b6e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: fmc@ietf.org Subject: [fmc] RFPS (request for problem statement) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:43:01 -0000 This is a multi-part message in MIME format. --------------090104000100030807050605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Carl, I agree with this. The ITU requirements lead us along one path. The BBF requirements lead us along another shorter path. I think we have enough material to schedule a more formal BoF in Vancouver, but it would be nice if we could find a way to actually answer questions in this mailing list. I thought about giving some answers to Med's list of questions, but I quickly realized that would be missing the point almost entirely. Instead, it seems that almost everyone thinks we would be doing this work in service for some other SDO. Any such list of answers, it seems, has to be dreamt up on behalf of some other group. So, which SDO are we trying to please? Is it BBF, or ITU, or some other organization? It seems to me that we've mostly spent time going around in circles. If we do not know whom we are trying to please, we will never stop doing that. Would anyone care about formulating a candidate *IETF* vision of FMC -- completely disregarding any other SDO requirement? What does the _end user_ want? Regards, Charlie P. On 5/11/2012 8:05 AM, Carl Williams wrote: > > Hi Behcet, > > I think you should have a clear problem statement that everyone > agrees about the problem space -- that must be done -- otherwise what > are your requirements for. > > Carl > > > 2012. 5. 11. ?? 7:44? "Behcet Sarikaya" > ?? ??: > > Hi all, > > We are looking for volunteers to write a requirements draft. The work > will be based on the points already posted on the list by Med. > 1+ persons is needed. If interested drop a note to Dirk and me. > > Regards, > > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > _______________________________________________ fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. -- Regards, Charlie P. --------------090104000100030807050605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Carl,

I agree with this.  The ITU requirements lead us along one path.  The BBF requirements lead us along another shorter path.  I think we have enough material to schedule a more formal BoF in Vancouver, but it would be nice if we could find a way to actually answer questions in this mailing list.

I thought about giving some answers to Med's list of questions, but I quickly realized that would be missing the point almost entirely.  Instead, it seems that almost everyone thinks we would be doing this work in service for some other SDO.  Any such list of answers, it seems, has to be dreamt up on behalf of some other group.

So, which SDO are we trying to please?  Is it BBF, or ITU, or some other organization?    It seems to me that we've mostly spent time going around in circles.  If we do not know whom we are trying to please, we will never stop doing that.

Would anyone care about formulating a candidate *IETF* vision of FMC -- completely disregarding any other SDO requirement?   What does the _end user_ want?

Regards,
Charlie P.



On 5/11/2012 8:05 AM, Carl Williams wrote:

Hi Behcet,

  I think you should have a clear problem statement that everyone agrees about the problem space – that must be done – otherwise what are your requirements for.

Carl


2012. 5. 11. 오후 7:44에 "Behcet Sarikaya" <sarikaya2012@gmail.com> 님이 작성:
Hi all,

We are looking for volunteers to write a requirements draft. The work
will be based on the points already posted on the list by Med.
1+ persons is needed. If interested drop a note to Dirk and me.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc 

_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc



-- 
Regards,
Charlie P.

-- 
Regards,
Charlie P.
--------------090104000100030807050605-- From charles.perkins@earthlink.net Fri May 11 13:38:14 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E1721F85D2 for ; Fri, 11 May 2012 13:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 exol1u5fKrHO for ; Fri, 11 May 2012 13:38:13 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id A54C821F85C9 for ; Fri, 11 May 2012 13:38:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TMtPU/34vvZHZ7xsYSN/lGL2TnvH67fGavrotNxc4UDx2UcY730EeWrqOjalD9tj; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [12.207.18.42] (helo=[192.168.255.200]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SSwbJ-0007Lr-Ed; Fri, 11 May 2012 16:38:10 -0400 Message-ID: <4FAD789F.5010108@earthlink.net> Date: Fri, 11 May 2012 13:37:51 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carl Williams References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060905030006000300010004" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865c246f870ebd208913fa1935e9108066350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 X-Mailman-Approved-At: Mon, 14 May 2012 00:14:23 -0700 Cc: fmc@ietf.org Subject: [fmc] RFPS (request for problem statement) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:38:14 -0000 This is a multi-part message in MIME format. --------------060905030006000300010004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Carl, I agree with this. The ITU requirements lead us along one path. The BBF requirements lead us along another shorter path. I think we have enough material to schedule a more formal BoF in Vancouver, but it would be nice if we could find a way to actually answer questions in this mailing list. I thought about giving some answers to Med's list of questions, but I quickly realized that would be missing the point almost entirely. Instead, it seems that almost everyone thinks we would be doing this work in service for some other SDO. Any such list of answers, it seems, has to be dreamt up on behalf of some other group. So, which SDO are we trying to please? Is it BBF, or ITU, or some other organization? It seems to me that we've mostly spent time going around in circles. If we do not know whom we are trying to please, we will never stop doing that. Would anyone care about formulating a candidate *IETF* vision of FMC -- completely disregarding any other SDO requirement? What does the _end user_ want? Regards, Charlie P. On 5/11/2012 8:05 AM, Carl Williams wrote: > > Hi Behcet, > > I think you should have a clear problem statement that everyone > agrees about the problem space -- that must be done -- otherwise what > are your requirements for. > > Carl > > > 2012. 5. 11. ?? 7:44? "Behcet Sarikaya" > ?? ??: > > Hi all, > > We are looking for volunteers to write a requirements draft. The work > will be based on the points already posted on the list by Med. > 1+ persons is needed. If interested drop a note to Dirk and me. > > Regards, > > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > _______________________________________________ fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. --------------060905030006000300010004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Carl,

I agree with this.  The ITU requirements lead us along one path.  The BBF requirements lead us along another shorter path.  I think we have enough material to schedule a more formal BoF in Vancouver, but it would be nice if we could find a way to actually answer questions in this mailing list.

I thought about giving some answers to Med's list of questions, but I quickly realized that would be missing the point almost entirely.  Instead, it seems that almost everyone thinks we would be doing this work in service for some other SDO.  Any such list of answers, it seems, has to be dreamt up on behalf of some other group.

So, which SDO are we trying to please?  Is it BBF, or ITU, or some other organization?    It seems to me that we've mostly spent time going around in circles.  If we do not know whom we are trying to please, we will never stop doing that.

Would anyone care about formulating a candidate *IETF* vision of FMC -- completely disregarding any other SDO requirement?   What does the _end user_ want?

Regards,
Charlie P.



On 5/11/2012 8:05 AM, Carl Williams wrote:

Hi Behcet,

  I think you should have a clear problem statement that everyone agrees about the problem space – that must be done – otherwise what are your requirements for.

Carl


2012. 5. 11. 오후 7:44에 "Behcet Sarikaya" <sarikaya2012@gmail.com> 님이 작성:
Hi all,

We are looking for volunteers to write a requirements draft. The work
will be based on the points already posted on the list by Med.
1+ persons is needed. If interested drop a note to Dirk and me.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc 

_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc



-- 
Regards,
Charlie P.
--------------060905030006000300010004-- From Dirk.von-Hugo@telekom.de Mon May 14 01:46:16 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388E721F85AA for ; Mon, 14 May 2012 01:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6, 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 n-gqPtPfdEPt for ; Mon, 14 May 2012 01:46:14 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7421F85A4 for ; Mon, 14 May 2012 01:46:13 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 14 May 2012 10:45:11 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.36]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 14 May 2012 10:45:10 +0200 From: To: , Date: Mon, 14 May 2012 10:45:11 +0200 Thread-Topic: [fmc] List description Thread-Index: Ac0vsqEkmozztlv+Rsaj+Mee+DdohwB+pGlw Message-ID: <05C81A773E48DD49B181B04BA21A342A27979FB3C8@HE113484.emea1.cds.t-internal.com> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr><60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462024D6634@ftrdmel0.rd.francetelecom.fr> <05C81A773E48DD49B181B04BA21A342A2796F6C4D7@HE113484.emea1.cds.t-internal.com> <4FAD7327.1010006@earthlink.net> In-Reply-To: <4FAD7327.1010006@earthlink.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mohamed.boucadair@orange.com, fmc@ietf.org Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:46:16 -0000 Hi Charlie, Unfortunately I don't know about that backbround at BBF (and 3GPP). I guess= they wanted to keep the issue list as detailed and short as possible to be= able to check the success ... But perhaps Allan who should be more involve= d in BBF can answer your question. > I guess that the BBF requirements have been crafted to be less rigorous than those suggested by the ITU. Do you know why? Best regards Dirk > Hello Dirk, I looked through the ITU document. It has a lot of interesting points. I noticed that it very clearly requires mobility management, e.g.: > Seamless service experiences and > Support of generalized mobility, which includes service mobility, > user, terminal device and network mobility. Reduced or partial > mobility may be supported in some specific networks. Of course we can always aim for the lowest possible interpretation of these words :-) I guess that the BBF requirements have been crafted to be less rigorous than those suggested by the ITU. Do you know why? If we were to work from the ITU document, we could probably get to a number of solid FMC requirements. It could be that these may already be satisfied by existing IETF protocols under certain assumptions, but it would be quite worthwhile to figure that out. Regards, Charlie P. On 4/11/2012 5:38 AM, Dirk.von-Hugo@telekom.de wrote: > Dear all, > As far as I understand here we are all on track - we currently have to di= scuss and come hopefully to a conclusion which aspects of interoperation be= tween fixed and mobile networks to provide a unified service to end users c= an be solved by means of IETF i.e. e.g. proposing a BCP of existing protoco= ls or adaptation and enhancement of approaches. > > If that is what could be reflected within the requirements then I would a= dd my issues here: > > - beside exchange of customer identity and profile (e.g. subscription det= ails such as 'silver/gold/platinum' contract and status such as e.g. 'busy'= , 'available', 'be right back' etc.) and related operator policies also the= characteristics of currently used terminals is an important aspect both fo= r service provisioning (e.g. adaptation of information data rate to screen = size and resolution) and efficient network resource usage. > > Do you think that would make sense and could be translated into IETF requ= irements? > > Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y= .2802 "Fixed-mobile convergence general requirements" has been published he= re http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that det= ailed requirements for us cannot be derived therefrom easily ... > > Best regards > Dirk > -----Urspr=FCngliche Nachricht----- > Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pi= errick.seite@orange.com > Gesendet: Mittwoch, 11. April 2012 12:16 > An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsso= n.com > Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org > Betreff: Re: [fmc] List description > > Hi, > > I definitely agree we should elaborate first on requirements from an "FMC= " standpoint. And I'd add "from and IETF standpoint" also... > > Before talking about solutions, I think we should try to get consensus on= a list of clear requirements with their Motivation/use-case. > > Then, we could talk about solutions and go to a gap analysis, with respec= t to work done in other WG (or SDOs), to see what protocol extensions are n= eeded. > > Pierrick > >> -----Message d'origine----- >> De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de >> mohamed.boucadair@orange.com >> Envoy=E9 : mercredi 11 avril 2012 08:07 >> =C0 : Donald Eastlake; David Allan I >> Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org >> Objet : Re: [fmc] List description >> >> Dear all, >> >> There is no recommended solution for the FMC case, because there are >> not clear requirements for that case. >> I have suggested to Behcet to further elaborate on the requirements >> from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: >> >> * The current HOST_ID effort in INTAREA WG is restricted to the >> analysis of potential channels which may convey the HOST_ID information >> * A recommendation is likely to be added.but in the context of address >> sharing (RFC6269) >> * FMC proponents should elaborate further their requirements for the >> HOST_ID >> (1) Required only during session initialization? >> (2) Required for all transport protocols? >> (3) Host modification should be avoided or it does not harm? >> (4) Which entity will use the HOST_ID information: proxy servers, else? >> (4a) Packet inspection is required? No? >> (4b) Performance impact >> (5) Which entity will set the HOST_ID information? >> >> BTW, I discussed this point with some colleagues and it seems using >> port sets would be more appropriate for the FMC case (i.e., >> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- >> 01#section-3.3). >> >> If port sets are used, a dedicated notification channel is needed to >> report assigned port sets. FYI, I'm working with Dean on this point. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >>> part de Donald Eastlake >>> Envoy=E9 : mercredi 11 avril 2012 00:55 >>> =C0 : David Allan I >>> Cc : sarikaya@ieee.org; fmc@ietf.org >>> Objet : Re: [fmc] List description >>> >>> I think that the nat-reveal draft, while it discusses 8 different >>> possible solutions, does not actually propose any specific solution >>> for any specific problem, such as the FMC/NAT problem. >>> >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >>> >>> On Tue, Apr 10, 2012 at 5:17 PM, David Allan I >>> wrote: >>>> Thanks Donald. >>>> >>>> So it is being addressed elsewhere. It is NOT the focus of >>> this effort... >>>> >>>> Given that clarification, this discussion is going circular. >>> We now revert to "what IETF FMC work are we discussing?" >>>> >>>> Dave >>>> >>>> -----Original Message----- >>>> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >>>> Sent: Tuesday, April 10, 2012 2:07 PM >>>> To: David Allan I >>>> Cc: sarikaya@ieee.org; fmc@ietf.org >>>> Subject: Re: [fmc] List description >>>> >>>> I think this is the draft: >>>> >>> https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- >>> analysis/ >>>> That is an INTAREA WG draft. >>>> >>>> Thanks, >>>> Donald >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>> 155 Beaver Street, Milford, MA 01757 USA >>>> d3e3e3@gmail.com >>>> >>>> >>>> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I >>> wrote: >>>>> Hi Bechet: >>>>> >>>>> You did not provide a useful answer. You simply pointed out >>> to me things I've said (repeatedly). >>>>> >>>>> I asked: >>>>> 1) Where was the draft you referred to? >>>>> 2) What WG is working on it? >>>>> 3) Is it the topic of the effort represented by this list? >>>>> >>>>> Can you please clarify... >>>>> >>>>> Thanks >>>>> Dave >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>> Sent: Tuesday, April 10, 2012 1:29 PM >>>>> To: David Allan I >>>>> Cc: fmc@ietf.org >>>>> Subject: Re: [fmc] List description >>>>> >>>>> Hi Dave, >>>>> >>>>> In November 2011, 3GPP-BBF Workshop >>>>> chaired by >>>>> >>>>> Dave Allan (BBF), Balazs Bertenyi (3GPP) >>>>> >>>>> issued Chairmen's Summary slides at: >>>>> >>> http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 >>>>> 6.zip >>>>> >>>>> which stated on Slide 4 >>>>> >>>>> In case of RG with NATs additional mechanisms are needed to >>> enable this. Jointly encourage IETF work on such mechanisms. >>>>> >>>>> That's all I have to say. >>>>> >>>>> I think we should concentrate on IETF work on FMC >>> discussions on this list. >>>>> >>>>> Kind regards, >>>>> >>>>> Behcet >>>>> >>>>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I >>> wrote: >>>>>> Hi Bechet: >>>>>> >>>>>>> Thanks for your mail. >>>>>> >>>>>>> Two points. >>>>>> >>>>>>> Point 1. Can you please clarify that you have expressed >>> your personal opinion not wearing any hats? >>>>>> >>>>>> Does it matter? >>>>>> >>>>>> Point 2. On: >>>>>> >>>>>>>> The outstanding headwound is a wifi connected UE behind a >>> NAT, and I >>>>>>>> believe that is already being addressed elsewhere in the IETF. >>>>>> >>>>>>> Yes, there is a draft called NAT Reveal Analysis draft. >>> It analyzes the problem and suggests very many solutions (5-6) >>> and there are even solutions not mentioned in NAT Reveal >>> Analysis draft. >>>>>> >>>>>> A pointer to the draft would be useful. And the WG context >>> it is being entertained in.... >>>>>> >>>>>>> So it is a difficult problem and maybe explains why so >>> many people are subscribed to this list. >>>>>> >>>>>> So is solving the NAT problem the purpose of this >>> endeavour? I did not get that. >>>>>> >>>>>> >>>>>> Cheers >>>>>> Dave >>>>>> >>>>>> _______________________________________________ >>>>>> fmc mailing list >>>>>> fmc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fmc >>>>> _______________________________________________ >>>>> fmc mailing list >>>>> fmc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fmc >>> _______________________________________________ >>> fmc mailing list >>> fmc@ietf.org >>> https://www.ietf.org/mailman/listinfo/fmc >>> >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > From charliep@computer.org Wed May 23 11:27:58 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360A721F878A for ; Wed, 23 May 2012 11:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqrVsqQtJkQj for ; Wed, 23 May 2012 11:27:57 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2C21F8764 for ; Wed, 23 May 2012 11:27:52 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.255.187]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SXGHo-0000B6-Be for fmc@ietf.org; Wed, 23 May 2012 14:27:52 -0400 Message-ID: <4FBD2C1E.9050706@computer.org> Date: Wed, 23 May 2012 11:27:42 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "fmc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ff83b9cee4584fe1a3383c21031ee087350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: [fmc] Hello out there... X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 18:27:58 -0000 Hello folks, Is there anything going on with FMC these days? I sent email out a couple of weeks ago. Since then it seems to have been silent (or else I just didn't receive any messages). What needs to be done next? -- Regards, Charlie P.