Re: [hiaps] Hiaps use cases

[<[e-mail]>]

Hi Dan, all,

Apologies for the delay to answer this message.

Please see inline.

Cheers,
Med

De : Dan Wing [mailto:[e-mail]]
Envoyé : mercredi 4 décembre 2013 00:49
À : [e-mail]
Cc : [e-mail]; Xueli; BOUCADAIR Mohamed IMT/OLN; [e-mail]
Objet : Re: [hiaps] Hiaps use cases


On Dec 3, 2013, at 9:08 AM, Behcet Sarikaya <[e-mail]<mailto:[e-mail]>> wrote:




On Mon, Dec 2, 2013 at 1:28 PM, Dan Wing <[e-mail]<mailto:[e-mail]>> wrote:


On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <[e-mail]<mailto:[e-mail]>> wrote:


I started a new tread on the use case issue that Med brought up.
Based on what Med said in his previous mail:

>IMHO before having solution-oriented discussion, let's see first if people
>understand well the problem space and the set of use cases identified
>so far.
for this we currently have:
http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-03.txt

It lists:

   (1)  Section 3.1: Carrier Grade NAT (CGN)

   (2)  Section 3.2: A+P (e.g., MAP )

   (3)  Section 3.3: Application Proxies

   (4)  Section 3.4: Provider Wi-Fi

   (5)  Section 3.5: Policy and Charging Architectures

   (6)  Section 3.6: Cellular Networks

   (7)  Section 3.7: Femtocells

   (8)  Section 3.8: Overlay Networks (e.g., CDNs)

   (9)  Section 3.9: Emergency Calls


Are these use case well understood? Any issues with them?

I understand the first 4.  I understand the rest less.  Specifically, overlay networks (8) I understand because I have chatted several times with Brandon, but the I-D doesn't adequately motivate the use-case.  Emergency calls (9) is all over the map -- discusses solutions (which I believe is out of scope for the document, or should be?), some of which cannot work (specifically the location when using VPN cannot work).
[Med] Some solutions are listed in that section to further explain why these solutions are not sufficient to address the problem. The text can be cleaned to focus only on the problem space. That's fair.

 Not sure of use-case #5
[Med] The issue here is how to correlate between the information received from the application function (mainly an external IP address/port assigned by the NAT), with the internal information received from the PEP (mainly the internal IP address/port number).
, 6
[Med] This issue is similar to the CGN case. This section can be merged with 3.1.
, or 7
.

-d




There is also interest in combining Med's use cases draft with the prefix sharing use case draft and also in the process concentrating on some of them like emergency calls, CGNs and prefix sharing.
What do you think?
Behcet

but none of those are the 'roaming' situation which I believe Dirk von Hugo was concerned with, where he wanted an identifier to persist across network attach points.  (Veering into solutions, I wonder if an MPTCP-like connection identifier would solve the problem, even if MPTCP itself isn't used).

-d







and
http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt
We are expecting a new draft on this and I know we already have some people working on it.
Regards,
Behcet
_______________________________________________
hiaps mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/hiaps