Subject: Re: [fmc] List description

From: <[email-masked]>
Date: Mon, 14 May 2012 10:45:11 +0200

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

<still catching up on FMC...>

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, [email-masked] wrote:
> 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,
>
> 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
>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la part de
>> [email-masked]
>> Envoyé : mercredi 11 avril 2012 08:07
>> À : Donald Eastlake; David Allan I
>> Cc : Dean cheng; [email-masked]; [email-masked]
>> 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 : [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
>>>
>>> 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
>>> =============================
>>> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>> 155 Beaver Street, Milford, MA 01757 USA
>>> [email-masked]
>>>
>>> On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
>>> <[email-masked]>  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:[email-masked]]
>>>> Sent: Tuesday, April 10, 2012 2:07 PM
>>>> To: David Allan I
>>>> Cc: [email-masked]; [email-masked]
>>>> 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
>>>> =============================
>>>>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>>   155 Beaver Street, Milford, MA 01757 USA
>>>>   [email-masked]
>>>>
>>>>
>>>> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
>>> <[email-masked]>  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:[email-masked]]
>>>>> Sent: Tuesday, April 10, 2012 1:29 PM
>>>>> To: David Allan I
>>>>> Cc: [email-masked]
>>>>> 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
>>> <[email-masked]>  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.
>>>>>>
>>>>>> <snipped to end>
>>>>>> Cheers
>>>>>> Dave
>>>>>>
>>>>>> _______________________________________________
>>>>>> fmc mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/fmc
>>>>> _______________________________________________
>>>>> fmc mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/fmc
>>> _______________________________________________
>>> fmc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/fmc
>>>
>> _______________________________________________
>> fmc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fmc
> _______________________________________________
> fmc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fmc
> _______________________________________________
> fmc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fmc
>