Subject: Re: [hiaps] Hiaps use cases

From: <[email-masked]>
Date: Wed, 15 Jan 2014 15:01:21 +0100

Hi Dan, all,

Apologies for the delay to answer this message.

Please see inline.

Cheers,
Med

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

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

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

On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hiaps

---

From: <[email-masked]>
Date: Wed, 15 Jan 2014 15:11:45 +0100

Dear Roland,

Please see inline.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : mercredi 4 décembre 2013 11:36
À : [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : AW: [hiaps] Hiaps use cases

Hi all,

regarding

RS: I do not understand why double NAT is not described or allowed

[Med] Where do you want to position the second NAT?

RS: do we have here also the use case for using private

Ipv4 addresses?

[Med] Yes.

RS: this use case seems similar to the WiFi use case and

belongs IMHO to the "use case" heterogeneous networks in general

[Med] Makes sense. Suggestions to re-organise the text are more than welcome.

RS: This is a general use case and must be discussed for all use cases
[Med] Not sure I got your point here. The issue captured in this use case is to determine which location server need to be contacted to get the location of the caller.

What about the use case where mobile and/or fixed access are backup links for each other,
e.g. BBF use case?
[Med] Increasing the serviceability of the RG can be indeed ensured by backup lines; with or without maintaining the same address assigned to the RG. I can understand also the backup procedure can be implemented with or without preserving session continuity. Now back to the host identification issue, can you explicit which issue are you referring to? Thanks.

Is it included in Overlay Networks?

Regards

Roland

Von: hiaps [mailto:[email-masked]] Im Auftrag von Dan Wing
Gesendet: Mittwoch, 4. Dezember 2013 00:49
An: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; von Hugo, Dirk; Mohamed Boucadair; Xueli
Betreff: Re: [hiaps] Hiaps use cases

It lists:

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).  Not sure of use-case #5, 6, or 7.

-d

-d

and