Subject: [fmc] List description

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 6 Apr 2012 10:52:20 -0500

Hi all,

This is the text Dirk and I submitted to IESG when they asked 2-3
paragraph list description:

The purpose of this list on Fixed Mobile Convergence (fmc)  is to be a forum to
discuss and analyze all the issues that have
   arisen so far or to likely come up in the future
    regarding aspects the Fixed
   Mobile Convergence that requires some action in IETF Intarea or
closely related areas.

    The scope of Fixed Mobile Convergence is limited to pure
interworking between
    fixed and mobile networks in
   serving access for multi-interface terminals or mobile hosts like todays'
   smartphones.  In the interworking scenario, the mobile network passes
   on the mobile subscribers policies to an IP network which happens
to be fixed,
   in order to maintain the end-to-end service level agreement and to
   support remote terminal and access network management.
   Explicitly, the fixed IP network must have partnership with the mobile
   network in Fixed Mobile Convergence interworking scenario.

   Currently identified issues to be discussed on the list include
   User Equipment identification and
   authentication, Femto Access Point management, device type
   identification, Carrier-Grade Network Address Translation (CGN)
related problems and
   mobility considerations including IP flow mobility and status
tracking of IP host.
   It is expected that related issues will arise that will also be
discussed on the list
   that require some protocol work to be done, probably not
   necessarily requiring to develop a new protocol but rather
requiring extensions to the existing protocols.

Regards,

Behcet

---

From: [email-masked]
Date: Fri, 6 Apr 2012 10:49:50 -0700

Dear Behcet, 

Thank you very much for sharing this descriptions submitted to IESG. 

But I am so confused by the descriptions because the same set of issues 
that were described in the text were also discussed last week with the 
presentation that you have kindly prepared.   I remember the outcome of 
our discussions were that we have "no" agreement to justify those are 
issues that need to be addressed by IETF.   In fact, some of them have 
already resolved by 3GPP and/or Broadband Forum. 

If I have missed something between our last week discussions at the IETF 
and now, could you please clarify what exactly are the problems on those 
issues, because, as it is written, I could not understand what are the 
problem descriptions that you have newly found needed to be addressed? 

In your text, you said...
Currently identified issues to be discussed on the list include: 

User Equipment identification and authentication, 
Femto Access Point management, 
device type identification, 
Carrier-Grade Network Address Translation (CGN) related problems and
mobility considerations including IP flow mobility and 
status tracking of IP host.

It is expected that related issues will arise that will also be discussed 
on the list that require some protocol work to be done, probably not 
necessarily requiring to develop a new protocol but rather requiring 
extensions to the existing protocols.

Many Thanks in advance. 
Tricci 

Behcet Sarikaya <[email-masked]> 
Sent by: [email-masked]
04/06/2012 08:52 AM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
[fmc] List description

Hi all,

The purpose of this list on Fixed Mobile Convergence (fmc)  is to be a 
forum to

   serving access for multi-interface terminals or mobile hosts like 
todays'

Regards,

Behcet
_______________________________________________
fmc mailing list
[email-masked]
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.

---

From: <[email-masked]>
Date: Sat, 7 Apr 2012 00:46:10 +0200

Hi,

I've read this description, but I didn't really get the problem you want to address, from the IETF standpoint. Typically, I'm surprised to not see reference to 3GPP and BBF which are specifying FMC architectures. What are the use-cases from these SDOs, do these SDOs have expressed needs for protocol extensions, is there liaison statements? What do "fix" and "mobile" mean from an IETF standpoint? And so on... I think this description raises fundamental questions regarding the problem (again, from the IETF standpoint). So, before calling for drafts (referring to your previous mail), the problem should be clarified first. Otherwise there is a risk to redo 3GPP/BBF work... Typically, you are referring to "Femto access point management"... Do you really think it is in the IETF scope? 

Pierrick  

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Behcet Sarikaya
> Envoyé : vendredi 6 avril 2012 17:52
> À : [email-masked]
> Objet : [fmc] List description
> 
> Hi all,
>

---

From: David Allan I <[email-masked]>
Date: Fri, 6 Apr 2012 18:55:06 -0400

HI

Another party heard from (Me).

The IETF is a protocol specification body, and I do not see any protocol specification here.

Further this is not a greenfield problem, s much of this is already done and dusted, and simply needs implementation agreements. As noted it is 3GPP and BBF networks working together, which is a project well underway in the respective SDOs.

The outstanding headwound is a wifi connected UE behind a NAT, and I believe that is already being addressed elsewhere in the IETF.

What am I missing?
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, April 06, 2012 3:46 PM
To: [email-masked]; [email-masked]
Subject: Re: [fmc] List description

Hi,

Pierrick  

> Behcet Sarikaya Envoyé : vendredi 6 avril 2012 17:52 À : [email-masked] 
> forum to discuss and analyze all the issues that have

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Apr 2012 10:32:26 -0500

Hi Tricci,

Firstly, please stop cc'ing to fmc-bounces.

The issues that require IETF protocol work (as explained at the end of the
list description) are the issues this mailing list I think should
concentrate In case the problem can be solved with existing means, the
SDOs, e.g. Broadband Forum can go ahead and develop requirements.

.Yes, some of the issues listed may not survive. CGN Issue is an example.
Maybe there are other issues as well.

This list of issues are given as an example because they were discussed in
IETF 83 FMC side meeting.

Hope it is clear now?

Behcet

On Fri, Apr 6, 2012 at 12:49 PM, <[email-masked]> wrote:

> presentation that you have kindly prepared.   I remember the outcome of our
> discussions were that we have "no" agreement to justify those are issues
> that need to be addressed by IETF.   In fact, some of them have already
> resolved by 3GPP and/or Broadband Forum.
>

>    - User Equipment identification and authentication,
>    - Femto Access Point management,
>    - device type identification,
>    - Carrier-Grade Network Address Translation (CGN) related problems and
>    - status tracking of IP host.
>
>  *Behcet Sarikaya <[email-masked]>*

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Apr 2012 10:47:07 -0500

Hi Pierrick,

On Fri, Apr 6, 2012 at 5:46 PM,  <[email-masked]> wrote:
> Hi,
>
> I've read this description, but I didn't really get the problem you want to
>address, from the IETF standpoint. Typically, I'm surprised to not see
> reference to 3GPP and BBF which are specifying FMC architectures.

Yes, there is reference, it is implicitly there.

>What are the use-cases from these SDOs, do these SDOs have expressed
>needs for protocol extensions, is there liaison statements?

Well, I would say, there is, maybe not in the form of an official
liaison statement.

Please kindly take a look at this report of 3GPP-BBF Workshop in San
Francisco in November 2010

page 42 has this text:

In case of RG with NATs additional mechanisms are needed to enable
this. Jointly encourage IETF work on such mechanisms.

The report is at this link:

http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Report/

which is public.

The above is mentioned as Issue 1 in the list description..

> What do "fix" and "mobile" mean from an IETF standpoint?

This is a good point. We said an IP network which happens to be fixed.
You may wish to add some more text.

> And so on... I think this description raises fundamental questions regarding
>the problem (again, from the IETF standpoint). So, before calling for drafts
>(referring to your previous mail), the problem should be clarified first.
> Otherwise there is a risk to redo 3GPP/BBF work.

No, if the issue requires new IETF protocol work, shouldn't we assume
that SDOs did not have it done before?

>.. Typically, you are referring to "Femto access point management"... Do you >
>really think it is in the IETF scope?

Please see above.

Regards,

Behcet

---

From: [email-masked]
Date: Mon, 9 Apr 2012 13:07:30 -0700

Dear Behcet, 

Thank you for your kind reminder on how should use the IETF mailing list. 
I will pay attention on this one. 

Regarding to you clarification, I am still confused.  If we have not 
agreed on the issues that need to be addressed by this mailing list, and 
some of them have been addressed by other IETF working groups already 
(e.g. CGN, NAT), why they are the issues presented to IESG for this FMC 
mailing list? 

Anyway, I am hoping that, from now on, we should focus on the actual FMC 
issue that needs to be addressed by IETF, if any, and not on the 
non-issue. 

Thanks.
Tricci 

04/09/2012 08:32 AM
Please respond to
[email-masked]

To
[email-masked]
cc
[email-masked]
Subject
Re: [fmc] List description

Hi Tricci,

Hope it is clear now?

Behcet

 

Many Thanks in advance. 
Tricci 

Please respond to
[email-masked]

To
[email-masked] 
cc

Subject
[fmc] List description

Hi all,

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Apr 2012 11:21:23 -0500

Hi Dave,

Thanks for your mail.

Two points.

Point 1. Can you please clarify that you have expressed your personal
opinion not wearing any hats?

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.

So it is a difficult problem and maybe explains why so many people are
subscribed to this list.

Regards,

Behcet

---

From: David Allan I <[email-masked]>
Date: Tue, 10 Apr 2012 14:32:54 -0400

> Point 1. Can you please clarify that you have expressed your personal opinion not wearing any hats?

Does it matter?

> 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.

<snipped to end>
Cheers
Dave

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Apr 2012 15:28:36 -0500

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-11046.zip

which stated on Slide 4

That's all I have to say.

I think we should concentrate on IETF work on FMC discussions on this list.

Kind regards,

Behcet

---

From: David Allan I <[email-masked]>
Date: Tue, 10 Apr 2012 16:32:27 -0400

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:[email-masked]] 
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: [email-masked]
Subject: Re: [fmc] List description

Hi Dave,

issued Chairmen's Summary slides at:
http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.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.

Kind regards,

Behcet

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 10 Apr 2012 17:06:55 -0400

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
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: David Allan I <[email-masked]>
Date: Tue, 10 Apr 2012 17:17:36 -0400

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:[email-masked]] 
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: [email-masked]; [email-masked]
Subject: Re: [fmc] List description

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 10 Apr 2012 18:54:51 -0400

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

---

From: David Allan I <[email-masked]>
Date: Tue, 10 Apr 2012 19:00:07 -0400

Understood,

But there is also the stateless-NAT work going forward, that also looks easily adapted to this role. Once a UE identity is associated with a port range, the traffic self identifies.

It seems to me that a common criteria of goodness could be applied. One correlation between identity and flows is via management, one is transactional (initial identification/authentication), the rest of the implementation and application of policy could be pretty much the same classification steps.

Cheers
Dave 

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 3:55 PM
To: David Allan I
Cc: [email-masked]; [email-masked]
Subject: 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

On Tue, Apr 10, 2012 at 5:17 PM, David Allan I <[email-masked]> wrote:
>> http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-110
>> 4
>> 6.zip
>>
>> which stated on Slide 4
>>
>>>>>The outstanding headwound is a wifi connected UE behind a NAT, and 
>>>>>I believe that is already being addressed elsewhere in the IETF.
>>>

---

From: <[email-masked]>
Date: Wed, 11 Apr 2012 08:06:37 +0200

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 

>De : [email-masked] [mailto:[email-masked]] De la 
>part de Donald Eastlake
>Envoyé : mercredi 11 avril 2012 00:55
>À : David Allan I
>Cc : [email-masked]; [email-masked]
>Objet : Re: [fmc] List description
>
>> Given that clarification, this discussion is going circular. 
>We now revert to "what IETF FMC work are we discussing?"
>>
>> Dave
>>
>>> In case of RG with NATs additional mechanisms are needed to 
>enable this. Jointly encourage IETF work on such mechanisms.
>>>
>>>>> Point 1. Can you please clarify that you have expressed 
>your personal opinion not wearing any hats?
>>>>
>>>> Does it matter?
>>>>
>>>> Point 2. On:
>>>>
>>>>> 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.
>>>>

---

From: <[email-masked]>
Date: Wed, 11 Apr 2012 12:15:32 +0200

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 respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick

> [email-masked]
> Envoyé : mercredi 11 avril 2012 08:07
> À : Donald Eastlake; David Allan I
> Cc : Dean cheng; [email-masked]; [email-masked]
> 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
> 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
>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Wed, 11 Apr 2012 13:42:54 +0200

Fully agree with his words.

On Wed, Apr 11, 2012 at 12:15 PM, <[email-masked]> wrote:

> 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 respect
> to work done in other WG (or SDOs), to see what protocol extensions are
> needed.
>
> Pierrick
>

-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/

---

From: <[email-masked]>
Date: Wed, 11 Apr 2012 14:38:15 +0200

Dear all,
As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protocols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would add my issues here:

- beside exchange of customer identity and profile (e.g. subscription details 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 for 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 requirements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that detailed requirements for us cannot be derived therefrom easily ...

Best regards
Dirk
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Mittwoch, 11. April 2012 12:16
An: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [fmc] List description

Hi,

Pierrick

---

From: [email-masked]
Date: Wed, 11 Apr 2012 18:07:03 -0700

Dear Dirk, 

I am wondering the aspects that you raised, do you think that they are 
belonged to the domain of 3GPP and BBF, and NOT IETF? 

Thanks.
Tricci 

<[email-masked]> 
Sent by: [email-masked]
04/11/2012 05:38 AM

To
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
cc
[email-masked], [email-masked], [email-masked]
Subject
Re: [fmc] List description

Dear all,
As far as I understand here we are all on track - we currently have to 
discuss and come hopefully to a conclusion which aspects of interoperation 
between fixed and mobile networks to provide a unified service to end 
users can be solved by means of IETF i.e. e.g. proposing a BCP of existing 
protocols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would 
add my issues here:

- beside exchange of customer identity and profile (e.g. subscription 
details 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 for 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 
requirements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation 
Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been 
published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it 
seems that detailed requirements for us cannot be derived therefrom easily 
...

Best regards
Dirk
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von 
[email-masked]
Gesendet: Mittwoch, 11. April 2012 12:16
An: [email-masked]; [email-masked]; 
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [fmc] List description

Hi,

Pierrick

--=_alternative 000625C5882579DE_ÿ

---

From: [email-masked]
Date: Wed, 11 Apr 2012 18:14:10 -0700

Dear Pierrick, 

You have raised the excellent point that we all need to figure out what 
are the requirements from "FMC" standpoint. 

But I am wondering, since 3GPP and BBF have been working on this FMC work 
for so long, wouldn't they have done the gap analysis already?  I.e. if 
they need work to be done in IETF, should they have asked us to work on 
them already? 

Why should we start from scratch to do our own analysis?    What do you 
think? 

Thanks.
Tricci 

Jong-Hyouk Lee <[email-masked]> 
Sent by: [email-masked]
04/11/2012 04:42 AM

To
[email-masked]
cc
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
Subject
Re: [fmc] List description

Pierrick

---

From: Xueli <[email-masked]>
Date: Thu, 12 Apr 2012 02:53:40 +0000

Hi Med,

Thanks a lot for your detailed information. 
You raised a very good point of the work. Then I would like to add few questions here.

Why do you think that the port set solution is more appropriate for FMC case? And do you mind to explain which definition of FMC case you mentioned here?
Port set solution may be one choice. But the huge configuration works on RGs could not be avoided, additionally, the RGs are the subscriber side, which even make 
the configuration work more difficult. 

BR
Li

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sent: Wednesday, April 11, 2012 2:07 PM
> To: Donald Eastlake; David Allan I
> Cc: Dean cheng; [email-masked]; [email-masked]
> 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
> 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
> 
> >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1
> 104
> >>> 6.zip
> >>>
> >>> which stated on Slide 4
> >>>

---

From: <[email-masked]>
Date: Thu, 12 Apr 2012 08:02:19 +0200

Dear Xue,

The scenario is as follows (without elaborating all flow exchanges):

   o  A CPE offers a shared WiFi to hosts which do not belong to the
      subscriber.
   o  A visiting UE uses that shared connection to access its services
   o  The visiting UE requests access to the service using a given
      method (e.g., authenticated portal)
   o  The CPE then assigns a private IPv4 address and a set of ports to
      this UE
   o  Then, the CPE reports the assigned port set to a service node
      together with other information such as external IPv4@/MAC@, etc.
      This information will be correlated with the user_id provided
      during the authentication phase.
   o  The CPE will use that port set for NAPTing packets from that
      visiting UE
   o  The set of ports (assigned by the CPE) and the external IP address
      (assigned to the CPE) are then sufficient to uniquely identify a
      UE.

The reporting phase can be avoided if the CPE is pre-configured with a static list of port sets to be used for visiting UEs. 

Before discussing whether this is complicated or not, let me first know if the scenario above makes sense to you.

I'm also interested to hear from you about other scenarios which may require "explicit" HOST_ID. Would it be possible to provide answers to the questions I asked below? Thanks. 

Cheers,
Med

>part de Xueli
>Envoyé : jeudi 12 avril 2012 04:54
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; Donald Eastlake; David Allan I
>Why do you think that the port set solution is more 
>appropriate for FMC case? And do you mind to explain which 
>definition of FMC case you mentioned here?
>Port set solution may be one choice. But the huge 
>configuration works on RGs could not be avoided, additionally, 
>the RGs are the subscriber side, which even make 
>> There is no recommended solution for the FMC case, because 
>there are not
>> clear requirements for that case.
>> * A recommendation is likely to be added.but in the context 
>of address sharing
>> (RFC6269)

---

From: Xueli <[email-masked]>
Date: Fri, 13 Apr 2012 08:01:09 +0000

Dear Med, 

Thanks so much for your detailed explanation. 
I am very glad to share some opinions as follows.

Let's see what are the scenarios prior to the discussion about the detailed port set solution.

There are several other general scenarios, such as the mobile subscriber is attached to
home WiFi or to the 3GPP femtocell  (H(e)NB) , where the mobile subscriber establishes 
traffic transporting via the fixed broadband network.
In these scenarios, WiFi is converged into RG (residential gateway), additionally even femtocell maybe 
converged later. Here the UEs must be behind RGs for services, where RG with NAT.

Let's back to the solutions.
In case of RG with NAT, it is not easy work to achieve the port set solution.
The RG is the user device, which doesn't belong to the operators. Even more, it 
seems not possible at all to do pre-configured on RGs.

In addition, mentioned in the ps draft, the issue #2, which is the similar requirement essentially, also needs solutions. 
Here, the port set would not work, either.

During the FMC work, we should concentrate on possible protocol solutions in IETF later. What about your idea?:)

Cheers
Li

---

From: [email-masked]
Date: Fri, 13 Apr 2012 01:44:06 -0700

Dear Li, 

Please allow me to ask a simple question...

If the RG is not managed and controlled by the operator, why should the 
operator be responsible to solve the problem for the user's device behind 
the RG? 

Could you please explain?  Thanks
Tricci 

Xueli <[email-masked]> 
04/13/2012 01:01 AM

To
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [fmc] Issue #1: Identification (was RE:  List description)

Dear Med, 

Let's see what are the scenarios prior to the discussion about the 
detailed port set solution.

There are several other general scenarios, such as the mobile subscriber 
is attached to
home WiFi or to the 3GPP femtocell  (H(e)NB) , where the mobile subscriber 
establishes 
traffic transporting via the fixed broadband network.
In these scenarios, WiFi is converged into RG (residential gateway), 
additionally even femtocell maybe 
converged later. Here the UEs must be behind RGs for services, where RG 
with NAT.

Let's back to the solutions.
In case of RG with NAT, it is not easy work to achieve the port set 
solution.
The RG is the user device, which doesn't belong to the operators. Even 
more, it 
seems not possible at all to do pre-configured on RGs.

In addition, mentioned in the ps draft, the issue #2, which is the similar 
requirement essentially, also needs solutions. 
Here, the port set would not work, either.

During the FMC work, we should concentrate on possible protocol solutions 
in IETF later. What about your idea?:)

Cheers
Li

---

From: Xueli <[email-masked]>
Date: Fri, 13 Apr 2012 08:56:16 +0000

Hi Tricci,

The short answer is traffic control or we say, policy control.
The operator should control the traffic from their subscribers, that is the main point.
I think the section 4.1 of the ps draft(http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt) would be helpful. :)

BR
Li

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 13, 2012 4:44 PM
To: Xueli
Cc: [email-masked]; [email-masked]
Subject: Re: [fmc] Issue #1: Identification (was RE: List description)

Dear Li,

If the RG is not managed and controlled by the operator, why should the operator be responsible to solve the problem for the user's device behind the RG?

Xueli <[email-masked]>

04/13/2012 01:01 AM

To

cc

Subject

Dear Med,

Cheers
Li

---

From: [email-masked]
Date: Fri, 13 Apr 2012 10:10:57 -0700

Dear Li, 

Thank you for your kind and prompt response, and your reference to your 
draft.  Yes. I have read the draft, and I am sorry to say that I don't 
quite agree most of the arguments. 

Unfortunately, with your answer, I am still confused.  Because, on one 
hand, you said that, "The RG is the user device, which doesn't belong to 
the operators.", and then, on the other hand, you said that, "The operator 
should control the traffic from their subscribers, that is the main point. 
 ". 

It almost sounds like to me, "well, I am the subscriber of the operator, I 
can do whatever I want to break the system and the operator just has to 
fix it." ? 

Is it the spirit of your consideration, by raising the issue to the 
operator who is not accountable on the issue that the user creates? 

IMHO, I can see that the operator should provide the FMC solution on the 
E2E system that they manage and have the control.  Hence, I have trouble 
to understand your logic. 

Cheers.
Tricci 

Xueli <[email-masked]> 
04/13/2012 01:56 AM

To
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject
RE: [fmc] Issue #1: Identification (was RE:  List description)

Hi Tricci,
 
The short answer is traffic control or we say, policy control. 
The operator should control the traffic from their subscribers, that is 
the main point.
I think the section 4.1 of the ps draft(
http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt) would be 
helpful. J
 
BR
Li

Dear Li, 

Xueli <[email-masked]> 

To

Dear Med, 

Cheers
Li

 
--------------------------------------------------------
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.

---

From: <[email-masked]>
Date: Mon, 16 Apr 2012 08:33:35 +0200

Dear Xue,

Please see inline.

Cheers,
Med

>De : Xueli [mailto:[email-masked]] 
>Envoyé : vendredi 13 avril 2012 10:01
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : [email-masked]
>Objet : RE: Issue #1: Identification (was RE: [fmc] List description)
>
>Dear Med, 
>
>In these scenarios, WiFi is converged into RG (residential 
>gateway), additionally even femtocell maybe 

Med: Agreed...but this is the same scenario I described. I was wondering if you have identified other scenarios which may raise the identification issue.

>seems not possible at all to do pre-configured on RGs.

Med: I won't agree nor object this analysis at this stage. Let's first agree on the requirements; a tentative list is provided below. We need provide answers to these questions:

(1) The HOST_ID MUST be set by a trusted device: Yes/No?
(1a) The RG MUST set the HOST_ID: Yes/No?
(1b) The RG MUST strip any existing HOST_ID received from the UE: Yes/No?
(1c) The UE can set the HOST_ID: Yes/No?
(1d) An Upstream service device MUST check the content of the HOST_ID: Yes/No?
(1e) If the answer to (1d) is Yes, which device? Xxxxx
(1f) Which information is used by this upstream device to identify the UE behind the NAT?
(2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No?
(3) All packets issued from the visiting UE MUST convey the HOST_ID: Yes/No?
(3a) Only TCP traffic issued from the visiting UE MUST convey the HOST_ID: Yes/No?
(3b) Only UDP traffic issued from the vision UE MUST convey the HOST_ID: Yes/No?
(4) The HOST_ID solution MUST be specific to IPv4: Yes/No?
(4a) The HOST_ID solution MUST be valid to IPv6: Yes/No?
(4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No?

>
>In addition, mentioned in the ps draft, the issue #2, which is 
>the similar requirement essentially, also needs solutions. 

Med: I disagree with you conclusion but let's first discuss the requirements.

>
>During the FMC work, we should concentrate on possible 
>protocol solutions in IETF later. What about your idea?:)

Med: IMHO before declaring a work is needed within IETF, we need to:

* Identify the issues with a list of functional requirements
* Assess whether existing tools can not be packaged to meet those requirements

---

From: <[email-masked]>
Date: Tue, 17 Apr 2012 14:59:08 +0200

Hi,

De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 12 avril 2012 03:14
À : Jong-Hyouk Lee
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]; BOUCADAIR Mohamed OLNC-NAD-TIP; SEITE Pierrick RD-RESA-REN; [email-masked]
Objet : Re: [fmc] List description

Dear Pierrick, 

You have raised the excellent point that we all need to figure out what are the requirements from "FMC" standpoint.   

But I am wondering, since 3GPP and BBF have been working on this FMC work for so long, wouldn't they have done the gap analysis already?  I.e. if they need work to be done in IETF, should they have asked us to work on them already?

Why should we start from scratch to do our own analysis?    

This is exactly what I meant: let's see what 3GPP/BBF have done before rushing on solutions J

What do you think? 

Pierrick 

Thanks. 
Tricci 

04/11/2012 04:42 AM 

To

cc

[email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked] 

Subject

		

Pierrick 

> > Donald E. Eastlake 3rd   +1-508-333-2270 <tel:%2B1-508-333-2270>  (cell)
> >>  Donald E. Eastlake 3rd   +1-508-333-2270 <tel:%2B1-508-333-2270>  (cell)

#email: jonghyouk (at) gmail (dot) com 
#webpage: http://sites.google.com/site/hurryon/ 
_______________________________________________
fmc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fmc <https://www.ietf.org/mailman/listinfo/fmc>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Apr 2012 10:43:13 -0500

Hi Pierrick,

On Tue, Apr 17, 2012 at 7:59 AM, <[email-masked]> wrote:

> Hi,****
>
> ** **
>
> ** **
>
> *De :* [email-masked] [mailto:[email-masked]]
> *Envoyé :* jeudi 12 avril 2012 03:14
> *À :* Jong-Hyouk Lee
> *Cc :* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; BOUCADAIR Mohamed OLNC-NAD-TIP; SEITE Pierrick RD-RESA-REN;
> [email-masked]
>
> *Objet :* Re: [fmc] List description****
>
> ** **
>
> Dear Pierrick,
>
> Why should we start from scratch to do our own analysis?    ****
>
> This is exactly what I meant: let’s see what 3GPP/BBF have done before
> rushing on solutions J
>

Let me clarify. This group is an IETF group and hence any future work this
group may come up with (I hope I am using the right words) belong to IETF.
IETF work is different than the SDO work. SDOs do their work, IETF does its
work.

Who is rushing on solutions? There are some discussions going on Issue #1
mentioned on IETF draft
draft-xue-intarea-fmc-ps-02.txt

and possible solutions mentioned on another IETF draft
draft-ietf-intarea-nat-reveal-analysis-01.txt.

I don't think anybody said Pierrick should not see what 3GPP/BBF have done
before on this or on other issues.

Regards,

Behcet

snipped the rest.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Apr 2012 11:14:23 -0500

Hi Med,

> (4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No?

Yes, agreeing on the requirements (for each issue set) is a good idea.

Question for clarification: are the above referring to only Sections
3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where
HOST_ID is specifically used?

I guess you mean for the requirements, we can remove the ones that are
answered no? By consensus? How?

Behcet

---

From: [email-masked]
Date: Tue, 17 Apr 2012 09:55:40 -0700

Dear Behcet, 

I must be missing something?

I sincerely don't understand where are all these requirements come from 
the SDO which are developing the FMC solution today?  Could you please 
identify for which SDO's FMC related specifications or LS to IETF have 
requested these requirements to be addressed by IETF? 

As far as my understanding, the fundamental concept of Host ID has not 
been even considered by other SDO (e.g. 3GPP or BBF etc.) which is 
developing the FMC standards.  Hence, I sincerely don't understand why 
would this Host ID concept be brought up? 

Regards,
Tricci 

04/17/2012 09:14 AM
Please respond to
[email-masked]

To

Hi Med,

On Mon, Apr 16, 2012 at 1:33 AM,  <[email-masked]> wrote:

> Med: I won't agree nor object this analysis at this stage. Let's first 
agree on the requirements; a tentative list is provided below. We need 

Behcet

---

From: <[email-masked]>
Date: Tue, 17 Apr 2012 19:05:34 +0200

Dear Tricci,

Please refer to slide 12 of www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip.

Cheers,
Med
________________________________________
De : [email-masked] [[email-masked]]
Date d'envoi : mardi 17 avril 2012 18:55
À : [email-masked]
Cc : [email-masked]; [email-masked]; BOUCADAIR Mohamed OLNC/NAD/TIP
Objet : Re: [fmc] Issue #1: Identification (was RE: List description)

Dear Behcet,

I sincerely don't understand where are all these requirements come from the SDO which are developing the FMC solution today?  Could you please identify for which SDO's FMC related specifications or LS to IETF have requested these requirements to be addressed by IETF?

As far as my understanding, the fundamental concept of Host ID has not been even considered by other SDO (e.g. 3GPP or BBF etc.) which is developing the FMC standards.  Hence, I sincerely don't understand why would this Host ID concept be brought up?

Regards,
Tricci

04/17/2012 09:14 AM
Please respond to
[email-masked]

To

Hi Med,

Behcet

---

From: [email-masked]
Date: Tue, 17 Apr 2012 11:09:05 -0700

Dear Med, 

Thank you for your reference.  However, when I look at slide-12, I don't 
see any requirement suggesting the need for defining and obtaining the 
Host ID for a given UE?  Bullet #2 below is to identify the UE which is 
based on 3GPP concept and have their own specific identification defined 
by 3GPP. 

Thanks.
Tricci 
Provide a definition of “3GPP UE” to BBF 
•to be used in the context of BBF-3GPP interworking and convergence
Encourage IETF work on mechanisms to enable identifying individual UEs 
behind NAT/RGs

Extend SWa and STa to support existing BBF accounting
Continue studying the application of TDF in both BB2 and BB3 
configurations
•Provide further information on the TDF-based deployment scenario to BBF
Send Liaison Statement to outline the SaMOG architecture to BBF once it is 
sufficiently stable and ask for comments/feedback
Seek review from BBF before final approval of 3GPP stage-2 and stage-3

What do you think?   Thanks
Tricci 

04/17/2012 10:05 AM

To
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
RE : [fmc] Issue #1: Identification (was RE: List description)

Dear Tricci,

Please refer to slide 12 of 
www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip.

Cheers,
Med

Dear Behcet,

Regards,
Tricci

04/17/2012 09:14 AM
Please respond to
[email-masked]

To

Hi Med,

Behcet

---

From: <[email-masked]>
Date: Wed, 18 Apr 2012 07:40:12 +0200

Dear Tricci,

Please see inline.
Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]]
Envoyé : mardi 17 avril 2012 20:09
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]; [email-masked]
Objet : RE : [fmc] Issue #1: Identification (was RE: List description)

Dear Med,

Thank you for your reference.  However, when I look at slide-12, I don't see any requirement suggesting the need for defining and obtaining the Host ID for a given UE?
[Med] The text talks about means to identify an UE connected behind a NAT. The text does not talk about the type of the HOST_ID, who sets the HOST_ID, etc. This is what we are discussing here in this thread. We are trying to understand the use cases and check what HOST_ID (as discussed in http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01) is suitable for the FMC use case.

 Bullet #2 below is to identify the UE which is based on 3GPP concept and have their own specific identification defined by 3GPP.
[Med] Unless you will maintain a tunnel/session per UE, how can you identify an UE at the IP level (i.e., when you receive an IP packet with a source IP address shared between the owner of the RG and visiting UEs, how you will unambiguously distinguish the traffic of visiting UEs?).

Thanks.
Tricci
Provide a definition of "3GPP UE" to BBF
*to be used in the context of BBF-3GPP interworking and convergence
Encourage IETF work on mechanisms to enable identifying individual UEs behind NAT/RGs
Extend SWa and STa to support existing BBF accounting
Continue studying the application of TDF in both BB2 and BB3 configurations
*Provide further information on the TDF-based deployment scenario to BBF
Send Liaison Statement to outline the SaMOG architecture to BBF once it is sufficiently stable and ask for comments/feedback
Seek review from BBF before final approval of 3GPP stage-2 and stage-3

04/17/2012 10:05 AM

To

Dear Tricci,

Cheers,
Med

Dear Behcet,

Regards,
Tricci

04/17/2012 09:14 AM
Please respond to
[email-masked]

To

Hi Med,

Behcet

---

From: <[email-masked]>
Date: Wed, 18 Apr 2012 07:43:00 +0200

Hi Behcet,

The questions below will help us to (hopefully) select the solution to recommend from the list of solutions already identified in http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01. 

Cheers,
Med

>De : Behcet Sarikaya [mailto:[email-masked]] 
>Envoyé : mardi 17 avril 2012 18:14
>> Med: I won't agree nor object this analysis at this stage. 
>Let's first agree on the requirements; a tentative list is 
>provided below. We need provide answers to these questions:
>>

---

From: <[email-masked]>
Date: Thu, 19 Apr 2012 18:01:43 +0200

Hi all,

And furthermore there is the draft http://www.ietf.org/id/draft-gundavelli-v6ops-community-wifi-svcs-03.txt addressing requirements for supporting upcoming new Wi-Fi community    services (using both operators' and residentials' RGs) and mobility tools standardized in IETF that can be used for enabling these architectures including macro networks. Some people including authors of that draft have discussed the currently discussed requirements and the idea of merging them with above mentioned draft.

Beside that other FMC requirements or nice-to-have features such as terminal parameters may be seen as end-to-end problems where solutions already exist at application level (e.g. SIP, SVC, HTTP) - without other network entities in between to participate.
Those issues (and whether they are out of scope here) may also be mentioned in the to-be-written merged draft.

Comments welcome!

Best regards
Dirk
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Mittwoch, 18. April 2012 07:43
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [fmc] Issue #1: Identification (was RE: List description)

Hi Behcet,

Cheers,
Med